Re: [RFC/PATCH 4/5] daemon.c: accept extra service arguments

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 1, 2015, 03:39 UTC
Message-ID: <xmqqioelgzcn.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1425085318-30537-5-git-send-email-sbeller@google.com>

Stefan Beller <sbeller@google.com> writes:

Show 11 quoted lines

> Before 73bb33a (daemon: Strictly parse the "extra arg" part of the
> command - 2009-06-04) a client sending extra arguments could DoS
> git-daemon. 73bb33a fixed it by forbidding extra arguments.
>
> Allow arguments other than "host=" again as a preparation step for
> upload-pack2. "host=" if present must be the first argument
> though. The remaining arguments are concatenated by whitespace.
>
> So far none of supported services support extra arguments. Attempting
> to do will abort the service, just like how it is before. We might
> want to make them silently ignore extra arguments though.

The necessity of this means 3/5, hiding new stuff after "host=<name>\0", is not a viable strategy to extend the communication to "git daemon" in a backward compatible way so that new client can transparently talk with older daemon.

And if you accept that limitation and declare that new client MUST talk with a new git daemon, then there is not much point in hiding the extra arguments after "host=<name>\0". You can just declare that the new git daemon will accept arguments, including "host=<name>\0", as a series of "var=<val>\0" in separate packets, not as a part of the initial "<program> <path>" packet, for example.

One thing 3/5 and 4/5 will give you is to allow old clients to talk to the new git daemon if the way new programs spawned by git daemon must use that "hiding" trick, but I am not convinced that it is necessary to resort to that "hiding" trick in the first place.

Under the same "new client must talk with a new daemon, they cannot talk with existing daemon" limitation, I think you can arrange things this way by not touching daemon at all:

 * Keep the daemon protocol as "<program> <path>\0host=<name>\0".

 * New client, as it has to know that it is talking to a host with
   new enough Git, can ask "upload-pack-2" as <program>.

 * Design the protocol that the protocol backend programs such as
   upload-pack-2 (and other updated programs like receive-pack-2,
   trickle-pack, ...) talks in such a way that these "extra"
   parameters sent when client connects are sent as the first
   packet(s).

That way, the new daemon will take "<program> <path>\0host=<name>\0" and cannot take extra arguments at the end of that packet, but the new protocol backend programs do not need extra arguments given by the daemon to them anyway. Old clients will not ask to be connected to new upload-pack-2 and friends, but that is to be expected.