On Fri, Dec 14 2018, Jeff King wrote: > On Thu, Dec 13, 2018 at 11:53:05AM -0800, Jonathan Tan wrote: > >> > I don't know if there's a good solution. I tried running the whole >> > test suite with v2 as the default. It does find this bug, but it has >> > a bunch of other problems (notably fetch-pack won't run as v2, but >> > some other tests I think also depend on v0's reachability rules, >> > which v2 is documented not to enforce). >> >> I think Aevar's patches (sent after you wrote this) is a good start, and >> I have started looking at it too. > > Yeah, I'm excited to see it working with fetch-pack, as the current > behavior is to complain if you've tried to enable v2 config: > > $ git config protocol.version 2 > $ git fetch-pack git://github.com/git/git > fatal: support for protocol v2 not implemented yet > > I haven't actually run into it in the real world, but somebody might if > they have scripted around fetch-pack and are experimenting with v2. A > much friendlier behavior would be falling back to v1, but actually > supporting v2 is better still. :) > >> > - The "serve" command is funky, because it has no concept of whether >> > the "ls-refs" is for fetching or pushing. Is git-serve even a thing >> > that we want to support going forward? I know part of the original >> > v2 conception was that one would be able to just connect to >> > "git-serve" and do a number of operations. But in practice the v2 >> > probing requires saying "I'd like to git-upload-pack, and v2 if you >> > please". So no client ever calls git-serve. >> > >> > Is this something we plan to eventually move to? Or can it be >> > considered a funny vestige of the development? In the latter case, I >> > think we should consider removing it. >> >> Personally, I lean towards removing it, but there are arguments on both >> sides. In particular, removing "serve" means that both developers and >> users of Git need not be concerned with a 3rd endpoint, but preserving >> "serve" (and planning to migrate away from "upload-pack" and >> "receive-pack") means that we will only have one endpoint, eliminating >> confusion about which endpoint to use when making certain requests (when >> we add requests other than "fetch" and "push"). > > Yeah, at first glance I like the simplicity of a unified model. But the > separate fetch/push endpoints have been useful in the past. Separate > uploadpack/receive.hiderefs that I dealt with here are one form. Another > is that many people do HTTP access control using the endpoints. For > example, if I have a repo which is public-read and private-write, the > config we recommend in git-http-backend(1) is to lock down the > receive-pack access using webserver config. > > If all the webserver sees is "somebody wants to connect to git-serve", > it doesn't know if it should be challenging them for authentication or > not. It would have to start peeking into the git-serve conversation to > see what the client actually wants to do. That's _possible_ to do, but > it gets pretty awkward with existing webserver tools (whereas matching > the URI endpoint is pretty easy). > > Ditto for locked down ssh sessions like git-shell (or custom solutions > like gitolite). Right now we can "git-upload-pack is OK on this repo, > git-receive-pack is not". But blindly running "git serve" would be > dangerous. In this case I think we have a few more options, because the > user has always already authenticated. So we can just tell "git serve" > via the environment whether the user is authorized for push. It's harder > with HTTP because most setups avoid even challenging for auth unless > it's necessary. > > So I'm a bit worried that the unified endpoint model is going to be a > dead end, at which point carrying around git-serve just makes things > more complicated. This is from wetware memory of something discussed at a previous Git Merge, so I may have (inadvertently) made it up, but wasn't part of the idea of "git-serve" to have an extensible next-gen protocol where we could add new actions & verbs unrelated to sending or receiving packs? E.g. client<->server optimistic cooperation like offloading a long-running "git-grep", "git log -G" etc. to a more powerful workhorse server, which would use "git-serve" as a routing layer. Of course that's not in itself an argument for having a general "serve" command, actually the opposite for the reasons you mention with locking down things. E.g. maybe I want to support server-side git-grep on my server, but not git-log, and if it's one command it becomes a hassle to do that via SSH config or HTTPD config for the reasons you mention. The upside would be that once a host understands "git serve" I'm more likely to be able to get past whatever middle layer there is between my client and the "git" binary on the other side. E.g. if I have a newly compiled "git" client/server binary, but something like GitLab's "gitaly" sitting between the two of us.
