On Sat, Sep 24, 2011 at 08:05:29AM +0200, Michael Haggerty wrote:
> This could be implemented by having a single local config option that
> enables the use of an in-tree .gitconfig file:
>
> git config core.useTreeConfig true
>
> (or whatever the correct naming convention would be). This option would
> default to false, so the in-tree config would only occur following an
> affirmative decision by the cloner.
But once you've verified that the config looks OK and turned this option
on, how do you protect yourself from malicious config entering the repo
through a fetch?
> If finer granularity is required, config options could be classified
> into "security-relevant" and "non-security-relevant" options, where the
> former group basically includes anything that can cause arbitrary code
> to be executed. Then there could be a "core.useTreeConfig = safeonly"
> option to allow only the harmless options.
This is the "can of worms" I referred to earlier. You have to start
classifying each option.
> I think the priority of config options (highest to lowest) should be
>
> $GIT_DIR/config
> in-tree .gitconfig
> ~/.gitconfig
> $(prefix)/etc/gitconfig
One catch with any precedence scheme is that there are certain config
constructs that cannot be overridden. For example, some options are
respected multiple times to form a list (e.g., remote fetch and push
refspecs). There's no way in you $GIT_DIR/config to say "forget all of
the previous values you saw for this key" that may have come from the
in-tree .gitconfig.
I think you could introduce a special syntax for that, maybe just:
# make a list with two elements
[foo]
bar = one
bar = two
# now let's imagine this is our "reset" syntax
bar =
# and now we can put in our own new values
bar = three
where the final value of the config above would be (three).
It's actually not a new problem with in-tree config, and it doesn't tend
to come up all that much because most config values are treated as
simple scalars, and later values overwrite earlier ones.
> Of course, just like for attributes, it would have to be decided which
> version of the .gitconfig to use in which situations.
I'm not sure it makes sense to have it in the tree at all. For
attributes it makes sense, because you are annotating a path at a
_specific_ revision. But config is often much more meta- than that.
Take textconv for an example. The gitattributes say "foo.pdf should use
the 'pdf' diff driver". That makes sense to go in a revision. But the
config will say "pdf files can be converted to text using
/usr/bin/pdftotext". That is not something that is tied to the revision
at all, and should exist outside of any revision. I.e., whether I am
doing a "git show" on the HEAD, or on some ancient commit, I would want
to use the same value, not whatever tool I used to convert PDFs years
ago.
-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