On 02/22, Jeff King wrote: > On Thu, Feb 22, 2018 at 03:19:40PM -0500, Jeff King wrote: > > > > To be clear, which of the following are you (most) worried about? > > > > > > 1. being invoked with --help and spawning a pager > > > 2. receiving and acting on options between 'git' and 'upload-pack' > > > 3. repository discovery > > > 4. pager config > > > 5. alias discovery > > > 6. increased code surface / unknown threats > > > > My immediate concern is (4). But my greater concern is that people who > > work on git.c should not have to worry about accidentally violating this > > principle when they add a new feature or config option. > > > > In other words, it seems like an accident waiting to happen. I'd be more > > amenable to it if there was some compelling reason for it to be a > > builtin, but I don't see one listed in the commit message. I see only > > "let's make it easier to share the code", which AFAICT is equally served > > by just lib-ifying the code and calling it from the standalone > > upload-pack.c. > > 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. > > -Peff 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. I mean you could do some complicated advertising of commands based on the endpoint you hit, but then what does that mean if you're hitting the git-serve endpoint where you should presumably be able to do any operation. -- Brandon Williams
