Re: What's cooking in git.git (Aug 2010, #05; Sat, 21)
- From
Greg Brockman <gdb@mit.edu>
- Date
- Aug 23, 2010, 01:47 UTC
- Message-ID
- <AANLkTin26gfGTZyo+ZzG8s-FBTvY2Q9tYgYAQ70f8Lx=@mail.gmail.com>
- In-Reply-To
- <7v4oen5clj.fsf@alter.siamese.dyndns.org>
Show 8 quoted lines
> * gb/shell-ext (2010-07-28) 3 commits > - Add sample commands for git-shell > - Add interactive mode to git-shell for user-friendliness > - Allow creation of arbitrary git-shell commands > > I am not very happy about adding these backdoors to git-shell, which is > primarily a security mechanism, and obviously security and backdoor do not > mix well.
That's a fair concern, and I would not feel slighted if you decided to abandon the patches for this reason. However, are there things we could do to mitigate the chance of an attacker taking advantage of the new functionality? For example, what about requiring the git shell user to set a config variable in order to enable the extended shell? Or alternatively, as someone suggested previously, require the root user to drop some enabling config into /etc? Do you have any particular threat models in mind?
For what it's worth, at this point my $project is using the git-shell in production. It's been a timesaver for us to just be able to give our devs a single ssh string (git@xvm.mit.edu) and let them figure out which repositories are available by themselves. This will probably become somewhat less vital once we've deployed gitweb, but even then it will be nice to be able to do repository discovery from the command line.
Greg