]> git.ipfire.org Git - thirdparty/git.git/commit - connect.c
daemon: Strictly parse the "extra arg" part of the command
authorShawn O. Pearce <spearce@spearce.org>
Fri, 5 Jun 2009 01:33:32 +0000 (18:33 -0700)
committerJunio C Hamano <gitster@pobox.com>
Sat, 6 Jun 2009 20:27:52 +0000 (13:27 -0700)
commit73bb33a94ec67a53e7d805b12ad9264fa25f4f8d
treecf0aef3b108d4c26223c530ffa80c151dcf6cd02
parent6c7f58d6f691c1091b90b0891e94c91e20fd6054
daemon: Strictly parse the "extra arg" part of the command

Since 1.4.4.5 (49ba83fb67 "Add virtualization support to git-daemon")
git daemon enters an infinite loop and never terminates if a client
hides any extra arguments in the initial request line which is not
exactly "\0host=blah\0".

Since that change, a client must never insert additional extra
arguments, or attempt to use any argument other than "host=", as
any daemon will get stuck parsing the request line and will never
complete the request.

Since the client can't tell if the daemon is patched or not, it
is not possible to know if additional extra args might actually be
able to be safely requested.

If we ever need to extend the git daemon protocol to support a new
feature, we may have to do something like this to the exchange:

  # If both support git:// v2
  #
  C: 000cgit://v2
  S: 0010ok host user
  C: 0018host git.kernel.org
  C: 0027git-upload-pack /pub/linux-2.6.git
  S: ...git-upload-pack header...

  # If client supports git:// v2, server does not:
  #
  C: 000cgit://v2
  S: <EOF>

  C: 003bgit-upload-pack /pub/linux-2.6.git\0host=git.kernel.org\0
  S: ...git-upload-pack header...

This requires the client to create two TCP connections to talk to
an older git daemon, however all daemons since the introduction of
daemon.c will safely reject the unknown "git://v2" command request,
so the client can quite easily determine the server supports an
older protocol.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
connect.c
daemon.c