On Wed, Sep 22, 2010 at 16:23, Tom Lane wrote:
Magnus Hagander <firstname.lastname@example.org> writes:
Any user can point their cvs client at the repository. And check out
an arbitrary branch, tag *or individual commit*. Doing so will create
a 50Mb sqlite database on the server with cache information about that
That basically means that git-cvsserver is completely useless in a
public scenario as it stands. An easier way to DOS our server is hard
to find, really.
Now, if we can limit this by IP address, that would be ok. I assume we
can do this for the NLS stuff - peter?
As for buildfarm members needing CVS - is it workable to require that
the maintainers of these set up their own git clone with git cvsserver
(over ssh or pserver) and restrict it locally to the IP(s) of their
If we're going to let people in by IP address, maybe we could let legacy
buildfarm members in by IP address. It doesn't seem particularly
helpful to expect each buildfarm owner to solve this problem for
themselves. I'd also note that if they could run git locally, they
wouldn't be needing cvsserver in the first place.
We could. It's currently on a freebsd vm though and I don't think we
can set per-server IP filters on those. (I was thinking iptables). We
could move it though - it doesn't *have* to be on the anonymous git
VM. It's just some extra resources.
Well, the use-case I was thinking of was Stefan. While he can't run
git on each and every animal, he certainly has *some* machine(s) on
the correct side of whatever firewall there may be that can run git.
Also, couldn't we just set up the cvsserver on its own VM with a limited
amount of disk space, and not worry too much about any "DOS threat"?
If somebody does do this, block them and reinitialize that server.
We could do that, but that could end up fighting a losing battle in
case some bot hits it.
I don't like deploying something with a known issue on it, sandboxed or not.