RE: [Best Practices Request] clean/smudge configuration - Avoiding the chicken and egg

From: Randall S. Becker <rsbecker@nexbridge.com>
Date: May 12, 2018, 20:29 UTC
Message-ID: <002f01d3ea2f$f816e990$e844bcb0$@nexbridge.com>

On May 11, 2018 3:26 PM, I wrote:

Show 33 quoted lines

> On May 10, 2018 10:27 PM, Junio C Hamano wrote:
> > "Randall S. Becker" <rsbecker@nexbridge.com> writes:
> >
> > > What if we create a ../.gitconfig like ../.gitattributes, that is
> > > loaded before .git/config?
> >
> > You should not forget one of the two reasons why clean/smudge/diff etc.
> > drivers must be given with a step of redirection, split between
> > attributes and config.  "This path holds text from ancient macs" at
> > the logical level may be expressed in .gitattributes, and then "when
> > checking out text from ancient macs, process the blob data with this
> > program to turn it into a form suitable for working tree" is given as
> > a smudge filter program, that is (1) suitable for the platform _you_
> > as the writer of the config file is using *AND* (2) something you are
> confortable running on behalf of you.
> >
> > We *deliberately* lack a mechanism to pay attention to in-tree config
> > that gets propagated to those who get them via "git clone", exactly
> > because otherwise your upstream may not just specify a "smudge"
> > program that your platform would be unable to run, but can specify a
> > "smudge" program that pretends to be a smudger, but is actually a
> > program that installs a keylogger and posts your login password and
> > bank details to this mailing list ;-)
> >
> > So, no, I do not think in-tree configuration will fly.
> 
> I agree, which is why I asked the original question instead of posting it as a
> formal patch. We would probably get a brand new CVE implementing the
> proposed proto-changes even if the original intent was internal trusted
> repositories only. That's why I asked this as a "Best Practices" type question,
> which I think I have a better idea on now. The actual situation is rather cool
> from a DevOps point of view, and whatever the ultimate solution is, might
> make for a nice presentation at some future conference 😉.

Here's where I ended up, from a solution standpoint:

0. Make sure the git scripts you use are always trusted using your favourite technique
1. Wrap the clone in a such a script to do the next two steps to avoid the usual problems of forgetting things
2. The clone script should use "git -c name=value clone repo" for all clean/smudge values needed that would otherwise be in .git/config if we had one which we don't
3. Have the script create/update .git/config using "git config --local name value" with all of the same clean/smudge values for subsequent operations.

From there, it seems that the contents of the smudged files are always correct, assuming the filter works of course. It was the use of -c that makes this work.

Sound about right?

Cheers, Randall