Re: Intricacies of submodules

[Jeremy Maitin-Shepard <jbms@cmu.edu>]

"Roman V. Shaposhnik" <rvs@sun.com> writes:

[snip]

> I'm sorry, but I don't buy this argument. If you have a malicious user
> gaining access to the repository all bets are off. To single out 
> in-tree .gitconfig as the only place which could be hacked seems to
> be a bit shortsighted and unfair. Any "executable" portion of your
> project that rarely gets eyeballed (such as Makefile infrastrucutre)
> could be used. In fact, under your scenario in-tree .gitconfig is
> likely to be the least of your worries. 

> And here's one more thing: in-tree .gitconfig and in-tree 
> update-my-git-settings.sh are absolutely identical as far
> as their security ramifications are concerned. If you really paranoid
> you have to eyeball either of them.

There is a huge difference: if you allow in-tree .gitconfig by default,
then git clone <some-repository> becomes an unsafe operation.  I can't
even inspect some arbitrary repository to _see_ if I like the code and
think it is safe very easily, since I'd normally do that by cloning the
repository.

Obviously actually executing untrusted code is unsafe regardless of
whether you type "git clone" or "make" to do it, but not everyone
intends to type "make" after checking out an unknown repository, and the
user is explicitly invoking make with the knowledge that it is running
whatever code is in the repository.  Similarly, if the user explicitly
calls some shell script in order to set things up, he is conscious that
he is performing a potentially unsafe operation.

As a silly analogy, it is currently perfectly safe to clone a repository
that has a text document containing instructions about committing
suicide, because there is the assumption that the instructions are not
automatically executed simply because they are on the user's hard drive.

[snip]

> Why? I'm really confused here. Unless I'm given a clear example of at
> least one setting that somehow becomes dangerous when stored inside
> in-tree .gitconfig, I really do consider such an enforcement to be
> as meaningful as enforcing that Git MUST manage source code and nothing
> else. You seemed to mention the trust issue. Well, why don't you trust
> the user to place whatever he wants in in-tree .gitconfig? And yes,
> we are talking about trustworthy users here and repositories that
> haven't been compromised.

Obviously any configuration option that specifies a shell command to run
is unsafe to specify in an in-tree .gitconfig.  As Junio noted,
smudge/clean commands are especially unsafe because they will be
executed even if the user only uses the clone command.

You actually seem to be the one assuming that a Git repository must
store source code (in particular source code that is then blindly
executed by anyone that clones the repository), as that is the only case
in which an in-tree .gitconfig can introduce no additional security
risk, since your security is then already completely dependent on
trusting the contents of the repository.

-- 
Jeremy Maitin-Shepard