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