On Thu, 2008-04-17 at 14:09 -0400, Jeremy Maitin-Shepard wrote: > > 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. Are you saying that a *remote* in-tree .gitconfig would be capable of affecting *local* system before the end of the clone operation? I find it very hard to believe. And if it is so, I'd love to be educated on the subject matter. What I (and to some extent Ping Yin) have been proposing is a completely different semantics -- the in-tree .gitconfig would only be able to affect your *local* operations. Doing clone of the *remote* repository is a safe operation under such assumptions. Once you cloned it, you might need to eyeball the content of .gitconfig if you're really paranoid. > 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. Same holds true for the semantics being proposed. The intsructions are *not* executed until you actually try to do something with your repository. There's a window of opportunity in which inspecting the content of .gitconfig is absolutely possible. > > 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. I'm sorry but I guess that went over my head. Is this the example of something that can affect local repository (and host!) during the clone operation? I tried to find documentation on the subject but googling for "git smudge" returns very few useful hits and the bits of documentation in gitattributes(5) don't really explain much. > 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. There are two things at play: first of all, I usually *do* trust the content of the repository. Call it matter of personal preference, but *for me* if you start with distrust -- there's very little you can do with that repository to begin with. To me it is a bit of red herring. On the other hand I understand where you're coming from and I definitely appreciate the need for a clone operation to be safe. So far, the only example of an unsafe setting that I have been given is smudge/clean filters. May be this is enough to shoot the very idea of an in-tree .gitconfig down, but I still don't really understand the *complete* semantics of these things. Can somebody explain, please? I hope this is not too much to ask. Thanks, Roman. -- 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
