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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 23, 2010, 16:33 UTC
Message-ID: <7vy6bx1e6x.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTin26gfGTZyo+ZzG8s-FBTvY2Q9tYgYAQ70f8Lx=@mail.gmail.com>

Greg Brockman <gdb@MIT.EDU> writes:

Show 16 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?

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.