On Mon, Mar 18, 2013 at 02:30:23PM +0530, Ramkumar Ramachandra wrote: > Jeff King wrote: > > I don't think you can avoid the 3-step problem and retain the safety in > > the general case. Forgetting implementation details for a minute, you > > have either a 1-step system: > > > > 1. Fetch and start using config from the remote. > > > > which is subject to fetching and executing malicious config, or: > > > > 1. Fetch config from remote. > > 2. Inspect it. > > 3. Integrate it into the current config. > > I don't understand your emphasis on step 2. Isn't the configuration > written by me? Why would it be malicious?
Maybe I am misunderstanding the use case, but when people talk about share config, they are often talking about pushing project-wide config out to developers. So the config is not necessarily written by you, but by somebody who had write access to the upstream repository. The obvious counterpoint is that people usually run "make" right after fetching, so they are trusting what they fetched already. And the counter-counterpoint is that yes, that's true, but at least with the "make" case they can use git to inspect the differences before running them. You may be able to tell that this is not the first time this discussion has happened. :) Personally, I do not think it is the end of the world for people to opt into the "automatically fetch and respect config" method for certain repositories (and that's why I wrote include.ref support a while ago). It's a security tradeoff that the user may want to make. But I also respect the argument that we should not be endorsing risky behavior by advertising such a feature (especially when the risk is quite subtle, as many users may not realize that git config can execute arbitrary code). > I've just started thinking about how to design something that will > allow us to share configuration elegantly [1]. Essentially, the > metadata repository will consist of *.layout files, one for each > repository to clone, containing the .git/config to write after cloning > that repository. So, a git.layout might look like: > > [layout] > directory = git > [remote "origin"] > url = git://github.com/git/git > [remote "ram"] > url = g...@github.com:artagnon/git > [remote "junio"] > url = git://github.com/gitster/git > > As you can see the [layout] is a special section which will tell our > fetcher where to place the repository. Everything else is meant to be > inserted into the repository's .git/config. However, I can foresee a > problem in scaling: when I ask a specific directory like a/b/c to be > populated (equivalent of repo sync `a/b/c`), it'll have to parse the > layout.directory variable of all the .layout files, and this can be > slow. So, maybe we should have a special _manifest.layout listing all > the paths? > > Further, I see this as a way to work with projects that would > otherwise require nested submodules like the Android project. What do > you think? Yeah, reading your layout description, this is less about git config in particular, and more about managing hierarchies of repos. Which I think is a fine thing to do, and is a sensible place to put config management (since you are probably executing arbitrary code as part of the layout tool anyway). But I don't have a real opinion on the design of such a tool. I have used repo only once or twice to deal with Android. For my own menagerie of small repos, I have a hacky custom tool that is mostly about deciding when there are items to be committed, pushed, or fetched in each repo; I never found the need to handle git config at all. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
