Re: Git cvsserver serious issue - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Git cvsserver serious issue
Date
Msg-id 4C9B1D76.3000304@dunslane.net
Whole thread Raw
In response to Re: Git cvsserver serious issue  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Git cvsserver serious issue  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers

On 09/23/2010 02:09 AM, Magnus Hagander wrote:
> On Thu, Sep 23, 2010 at 04:59, Andrew Dunstan<andrew@dunslane.net>  wrote:
>>>> 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.
>>>
>> Thinking about this some more, how about we do non-anonymous CVS over SSH
>> access to the git-cvsserver for the few buildfarm members that can't
>> currently handle using git (e.g. spoonbill)?
> Well, if we do that centrally, we are back to a dedicated VM (hint:
> we're most certainly not adding non-personal no-password accounts to
> one of the VMs used for critical services - it's bad enough we have
> Bruce's account there :P).
>
> I assume most buildfarm clients are off static IPs (at least as seen
> from the servers - they may be behind a NAT device, but that one
> having static out)? If so, it seems simply easier to use pserver...
>

Yes, I think we should have a VM. Is that so hard to do in these days of 
Xen etc? I'm surprised we can't run up a VM pretty much at the drop of a 
hat.

I was suggesting that the accounts would be protected using ssh keys. 
Password and IP address protection seem pretty weak to me. Passwords can 
be sniffed or attacked using brute force. IP addresses can be spoofed. 
But you're the SA, not me.

cheers

andrew


pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: top-level DML under CTEs
Next
From: Dimitri Fontaine
Date:
Subject: Re: Standby registration