Re: Intricacies of submodules

["Roman V. Shaposhnik" <rvs@sun.com>]

On Mon, 2008-04-14 at 18:13 -0700, Junio C Hamano wrote:
> Roman Shaposhnik <rvs@sun.com> 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.