Re: [PATCH v3 0/8] Hiding refs

[Duy Nguyen <pclouds@gmail.com>]

On Fri, Mar 14, 2014 at 11:45 PM, Shawn Pearce <spearce@spearce.org> wrote:
> On Fri, Mar 14, 2014 at 5:37 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>> On Wed, Mar 12, 2014 at 3:36 AM, Jeff King <peff@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.

Shouldn't vulnerable daemons be upgraded anyway? If they keep using
the vulnerable version for all these 5 years, I feel no sorry for new
clients DoSing them. Jeff's idea about "remote.*.useUploadPack2" still
applies here so after we attack the server once, it'll be black listed
for a while (or forever).

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

Right now we run this for ssh case: "ssh <host> git-upload-pack
<repo-path>". New client can do this instead

ssh <host> git-upload-pack <repo-path> <client capability flags>
-- 
Duy