> On Mar 24, 2025, at 11:28 PM, Jeff King <peff@xxxxxxxx> wrote: > > 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). Gitolite is a great software, but it also has its limitations. It couples authentication and authorization in the same system. However, I'm looking for something more flexible that I can plug whatever authentication or authorization system to the mix similar to git-http-backend paired with apache/nginx/h2o/etc. > > 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. That's a fair point. Perhaps writing my own restricted shell might be the best solution for what I'm looking for :/ > > 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). If you know any general restricted shell implementations please do tell. I'm looking for an SSH solution something pluggable like git-http-backend that I can build on top of. Honestly, git-shell's simplicity is what got my interest at first. The fact that it's not secure and not run frequently can change and be improved. - Ayman
