On Fri, Feb 23, 2018 at 01:09:04PM -0800, Brandon Williams wrote: > > By the way, any decision here would presumably need to be extended to > > git-serve, etc. The current property is that it's safe to fetch from an > > untrusted repository, even over ssh. If we're keeping that for protocol > > v1, we'd want it to apply to protocol v2, as well. > > This may be more complicated. Right now (for backward compatibility) > all fetches for v2 are issued to the upload-pack endpoint. So even > though I've introduced git-serve it doesn't have requests issued to it > and no requests can be issued to it currently (support isn't added to > http-backend or git-daemon). This just means that the command already > exists to make it easy for testing specific v2 stuff and if we want to > expose it as an endpoint (like when we have a brand new server command > that is completely incompatible with v1) its already there and support > just needs to be plumbed in. > > This whole notion of treating upload-pack differently from receive-pack > has bad consequences for v2 though. The idea for v2 is to be able to > run any number of commands via the same endpoint, so at the end of the > day the endpoint you used is irrelevant. So you could issue both fetch > and push commands via the same endpoint in v2 whether its git-serve, > receive-pack, or upload-pack. So really, like Jonathan has said > elsewhere, we need to figure out how to be ok with having receive-pack > and upload-pack builtins, or having neither of them builtins, because it > doesn't make much sense for v2 to straddle that line.
It seems like it would be OK if the whole code path of git-serve invoking upload-pack happened without being a builtin, even if it would be possible to run a builtin receive-pack from that same (non-builtin) git-serve. Remember that the client is driving the whole operation here, and we can assume that git-serve is operating on the client's behalf. So a client who chooses not to trigger receive-pack would be fine. -Peff
