Re: The git protocol and DoS
Show 26 quoted lines
> 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
Andreas Ericsson <ae@op5.se>