On Mon, 2008-04-14 at 18:13 -0700, Junio C Hamano wrote: > Roman Shaposhnik <rvs@xxxxxxx> writes: > > >> Don't get me wrong. I am not saying that everybody should start rolling > >> their own "sane environment setup script" and ship their project with it. > >> I am only suggesting it as a possible way to do your "policy enforcement" > >> without having to introduce in-tree .gitconfig, which I unfortunately see > >> no fundamental upsides but definite downsides (security included). > > > > And here comes my question: could you, please, elaborate on *technical* > > drawbacks of in-tree .gitconfig (such as security that you've > > mentioned). > > Just to name a few, as I do not see a point in spending time elaborating > in detail when there is an alternative without such security downsides. > > One of your examples was about a forced use of custom merge tool. > Consider in-tree .gitconfig that is always read for everybody that > describes such a tool. A malicious script named there is a security risk > for people who clone such a project. A smudge filter is even worse, as it > kicks in the minute you try to check out the project. 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. > These executable (not just merge tool or attribute filters) are designed > to be named by .git/config exactly because .git/config is designed to be > personal (i.e. "that _particular repository only_") and you can afford to > be environment and platform specific there. If you start describing them > in in-tree .gitconfig, they must be cross platform and (worse yet) > you have to make sure they are installed everywhere. I don't buy this argument either. First of all, there's a $PATH. On top of that even automounters learned how to deal with heterogeneous hosts efficiently ($HOST, $CPU, etc.) so I really don't think Git should have any problems. But the most obvious counterargument to your statement would be that quite a few developers (myself included) don't have a luxury of developing on a single architecture. Thus in-tree .gitconfig doesn't change anything -- *my* single Git repository has to provide settings that work on: [sparc|intel]-[Solaris|Linux]. I do have .git/config that accomplished that. I see no reason for in-tree .gitconfig to not be able to. > I'm too lazy to make a laundary list of what you can have in .git/config > with the current system (see Documentation/config.txt), but that part of > the system is built around the design that the configuration is specific > to the repository (and sharing what the user records in ~/.gitconfig > across repositories is in line with it). > > Unless you are willing to sift through all of them, mark which ones can be > overriden by in-tree .gitconfig and which ones cannot, and implement an > easy to use (by both the developers and the users) mechanism to enforce > the distinction, just changing the git_config() function to read from one > new place (i.e. in-tree .gitconfig) would not be a sufficient solution for > what you seem to want to do. 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. Thanks, Roman. P.S. Junio, I really don't want to waste your time especially since I get a feeling that our discussion has clearly moved into a domain of taste and preferences. But I had to refute your security and heterogeneity arguments simply because they don't seem to have any substance to them. -- 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
