Re: What's cooking in git.git (Aug 2010, #05; Sat, 21)

Greg Brockman [off-list ref] writes:

quoted

* 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?

My gut feeling is that the current requirement that the repository owner
has to have the subcommand directory for git-shell as an explicit sign
that he wants to enable this feature is probably the same as requiring a
configuration variable.  As I am not sure if a system-wide policy would
help in what way, I would say what we have is probably sufficient.

Comments from more folks who are involved in installations with users with
varying degree of trustworthiness would be helpful, though.