Re: The git protocol and DoS

Petr Baudis wrote:
> Dear diary, on Wed, Oct 19, 2005 at 10:00:05PM CEST, I got a letter
> where "H. Peter Anvin" <hpa@zytor.com> told me that...
> 
>>One way to do this would be to start the transaction by having the 
>>server transmit a cookie to the client, and to require the client to 
>>send a SHA1 of the (cookie + request) together with the request.  This 
>>would be done with a fairly short timeout.
> 
> 
>   If (well, it sounds like a good idea, so rather "when") you do this,
> it would be a good idea to do in a way that makes it easy to later add
> support for some kind of authentication (really, not everyone wants to
> give away ssh accounts). Let's say it works like:
> 
> [client]	git-upload-pack <path>
> [server]	challenge somethingnonsensical
> [client]	challenge-response <username>:sha1(somethingnonsensical<password>)
> [server]	All right, the pack goes like this...
> 
>   Suddenly you have support for hopefully secure authentication, and at
> the same time you have the cookie implemented in backwards-compatible
> fashion (in the sense that new client will be able to talk to old
> server) - just assume the username and password empty. This might be
> even hardcoded for now, just leave a room for its addition (in an
> elegant and compatible way) in the protocol, please.
> 

I think git-daemon would be better off without this, since
* A project rarely grants write access to the central repo (or whatever 
git has, I'm still fairly new to it) without being willing to give out 
ssh access, often limited by the ssh command whitelist.
* It's hard to do right.
* Passwords are never as secure or as convenient as public key 
authentication and there's no point in spending a lot of time 
re-inventing ssh.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html