On Sun, Mar 23, 2025 at 10:27:32PM -0700, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

So it seems like a reasonable goal. A more restricted approach might be
to provide a more formal hook/plugin interface. E.g., to run a hook
script with the command name and arguments, and have it return
success/failure to allow the to proceed.

That's not quite as flexible (in your approach I could replace what
upload-pack is doing entirely, cache its output, and so on). But it
might be harder for admins to screw up. I dunno.

Yeah, we usually try not to be overly flexible for that reason, but
given that "git shell" is so limited that rewriting its services
wholesale is not all that much of a deal, I think it is OK.

I however wonder if it is worth admins' time and effort to add
features to "git-shell" using this new facility, or if they are
better off using something more established like gitolite once they
want to go fancier beyond what the basic "git-shell" offers.

Yeah, I left my general opinions on git-shell unspoken. ;)

For features, I think you are probably better off with something like
gitolite (which I think does have some access control).

For security, I'd be a little scared of git-shell, just because it's not
run all that frequently and we've had issues with it before (e.g.,
integer overflows). If you're taking requests from untrusted clients,
you're probably better off configuring http service.

I also imagine there may be restricted shell implementations that are
more general and more battle-hardened, that you could configure to only
run a few commands. But I haven't looked at that space (because again,
I'd suggest just git-over-http).

-Peff