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

[Junio C Hamano <gitster@pobox.com>]

Stefan Beller <sbeller@google.com> writes:

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