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 😉. Cheers and thanks, Randall
