On May 11, 2018 3:26 PM, I wrote: > On May 10, 2018 10:27 PM, Junio C Hamano wrote: > > "Randall S. Becker" <rsbec...@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
