Greg Brockman <gdb@xxxxxxx> writes: >> * 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html