Re: Git cvsserver serious issue
От | Magnus Hagander |
---|---|
Тема | Re: Git cvsserver serious issue |
Дата | |
Msg-id | AANLkTikZkGvU4KQhmq6Q5ogs7ZLxnDwT0oC1-XKCPEgT@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Git cvsserver serious issue (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Git cvsserver serious issue
|
Список | pgsql-hackers |
On Wed, Sep 22, 2010 at 16:23, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> 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 >> head. > >> 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. > > Ugh. Indeed. >> 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 >> machines? > > 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. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: