RE: [Best Practices Request] clean/smudge configuration - Avoiding the chicken and egg
- Date: Sat, 12 May 2018 16:29:41 -0400
- From: "Randall S. Becker" <rsbecker@xxxxxxxxxxxxx>
- Subject: RE: [Best Practices Request] clean/smudge configuration - Avoiding the chicken and egg
On May 11, 2018 3:26 PM, I wrote:
> On May 10, 2018 10:27 PM, Junio C Hamano wrote:
> > "Randall S. Becker" <rsbecker@xxxxxxxxxxxxx> 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?