Shawn Pearce <> writes:

> Parsing the request line of git-daemon is easy. But we could make it
> easier. An alternative arrangement would be to add a new command line
> flag to git daemon like --command-filter that names an executable
> git-daemon will invoke after parsing the request line. It can pass
> along the client IP address, command request, repository name, and
> resolved repository path, and tie stdin/stdout to the client. This
> binary can decide to exec the proper git binary for the named command,
> or just exit to disconnect the client and refuse service. This makes
> it simple for a tool like gitolite to plug into the git-daemon
> authorization path, without needing to be the network daemon itself,
> worry about number of active connection slots, etc.

I think that is a good direction to go in, except that I am unsure
what kind of conversation do you want to allow between the "command
filter" helper and the client by exposing standard input and output
stream to to the helper.  If the client side has a matching "pre
negotiate command" helper support, then presumably the helpers can
discuss what Git protocol proper does not care about before deciding
to allow the connection go through, but until that happens, opening
the stdio streams up to the helper sounds like an accident waiting
to happen to me (e.g. "fetch-pack" connects, the server side helper
reads the first pkt-line from the client, says "OK, you may proceed"
to the daemon, then the daemon spawns the "upload-pack", which will
obviously see a corrupt request stream from "fetch-pack").
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to