Re: Proposal: sharing .git/config

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 = git@xxxxxxxxxx: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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]