Re: How to use git attributes to configure server-side checks?

From: Jeff King <peff@peff.net>
Date: Sep 24, 2011, 06:15 UTC
Message-ID: <20110924061555.GB13974@sigill.intra.peff.net>
In-Reply-To: <4E7D7329.7070800@alum.mit.edu>

On Sat, Sep 24, 2011 at 08:05:29AM +0200, Michael Haggerty wrote:

Show 8 quoted lines

> 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?

Show 5 quoted lines

> 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.

Show 6 quoted lines

> 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