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. Thanks, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. - 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.htmlReceived on Thu Oct 20 08:21:32 2005
This archive was generated by hypermail 2.1.8 : 2005-10-20 08:21:40 EST