Re: [PATCH v3] shell: allow overriding built-in commands

> On Mar 24, 2025, at 11:28 PM, Jeff King <peff@peff.net> wrote:
> 
> On Sun, Mar 23, 2025 at 10:27:32PM -0700, Junio C Hamano wrote:
> 
>> Jeff King <peff@peff.net> writes:
>> 
>>> 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).