On Fri, Mar 14, 2014 at 5:37 AM, Duy Nguyen <pclo...@gmail.com> wrote:
> On Wed, Mar 12, 2014 at 3:36 AM, Jeff King <p...@peff.net> wrote:
>> If the client is limited to setting a few flags, then something like
>> http can get away with:
>>   GET 
>> foo.git/info/refs?service=git-upload-pack&advertise-symrefs&refspec=refs/heads/*
>> And it does not need to worry about upload-pack2 at all. Either the
>> server recognizes and acts on them, or it ignores them.
>> But given that we do not have such a magic out-of-band method for
>> passing values over ssh and git, maybe it is not worth worrying about.
> git could go the same if we lift the restriction in 73bb33a (daemon:
> Strictly parse the "extra arg" part of the command - 2009-06-04). It's
> been five years. Old daemons hopefully have all died out by now. For
> ssh, I suppose upload-pack and receive-pack can take an extra argument
> like "advertise-symrefs&refspec=refs/heads/*" (daemon would use it too
> to pass the advertiment to upload-pack and receive-pack).

Heh. IIRC you are talking about the DoS attack for git-daemon where
you send an extra header and the process infinite loops forever? We
really don't want a modern client attempting to upgrade the protocol
with an ancient daemon to DoS attack that server.

> That would make all three not need to change the underlying protocol
> for capability advertisement. Old git-daemon, upload-pack and
> receive-pack will fail hard on the new advertisement though, unlike
> http. But that's no worse than upload-pack2.

You missed the SSH case. It doesn't have this slot to hide the data into.

>> Http can move to upload-pack2 along with the rest.
> Or maybe http may lead the rest to another way.
> --
> Duy
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to