"Roman V. Shaposhnik" <rvs@xxxxxxx> 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 -- 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
