From: Junio C Hamano Date: Mon, 23 Aug 2010 16:33:42 GMT Subject: Re: What's cooking in git.git (Aug 2010, #05; Sat, 21) Message-ID: <7vy6bx1e6x.fsf@alter.siamese.dyndns.org> In-Reply-To: Greg Brockman 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.