Re: Revamping the git protocol

On Thu, 20 Oct 2005, Petr Baudis wrote:
> 
> What's wrong with my scheme? That is, _reply_ with challenge to the
> upload-pack command.

Neither your not Peter's scheme seems to be at all worried about backwards 
compatibility, and I just don't see _why_.

Even if you can upgrade all servers (there aren't that many of them), why 
force a client upgrade when the protocol is designed to be extensible?

Especially for somethign that doesn't even _buy_ you anything right now.

In fact, I'm not even sure it buys you anything in the future. The thing 
is, SYN-flooding depends on overwhelming you with lots of simple packets. 
And since in the git protocol, the expense is not in the _packets_ but in 
the server-side packing and data transfer, I don't see the point.

If you want to DoS a git pack server, you open a hundred _real_ git 
connections to it, carefully selected so that they get unique packs (so 
that the server can't cache them). You don't need to have some distributed 
denial-of-service attack with lots of magic packets.

This is why the git daemon already limits the clients to 25 by default or 
something like that - it doesn't want to put too much strain on the 
server.

A much more important thing the git daemon could do is to kill connections 
from the same IP address when there's more than 25 pending ones. The 
daemon actualy has the infrastructure for that - it's why it doesn't just 
count its children, it actually saves child information away (it just 
doesn't _use_ it for anything right now).

Similarly, git-upload-pack can be future-proofed by having it have some 
data transfer timeout: if it doesn't make any progress at all in <n> 
seconds, just kill itself. Things like _that_ are likely to be a lot more 
important, I suspect.

And no, I don't think th egit protocol should do authentication. It's 
hard. If you want to do authentication, you need to do encryption too, and 
then you should do something else (but the git protocol _does_ work fine 
over an encyrpted channel, so the "something else" might be to have some 
secure web interface tunnel protocol or similar, and then just support 
"git over https" or something ;).

			Linus
-
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