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:

quoted

"Randall S. Becker" [off-list ref] writes:

quoted

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.

quoted

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