{"thread":{"id":"48474","subject":"RE: [Best Practices Request] clean/smudge configuration - Avoiding the chicken and egg","startedAt":"2018-05-12T20:29:54Z","lastAt":"2018-05-12T20:29:54Z","messageCount":1,"participants":["Randall S. Becker"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"347470","messageId":"002f01d3ea2f$f816e990$e844bcb0$@nexbridge.com","threadId":"48474","inReplyTo":null,"subject":"RE: [Best Practices Request] clean/smudge configuration - Avoiding the chicken and egg","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2018-05-12T20:29:41Z","receivedAt":"2018-05-12T20:29:54Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 11, 2018 3:26 PM, I wrote:\n> On May 10, 2018 10:27 PM, Junio C Hamano wrote:\n> > \"Randall S. Becker\" <rsbecker@nexbridge.com> writes:\n> >\n> > > What if we create a ../.gitconfig like ../.gitattributes, that is\n> > > loaded before .git/config?\n> >\n> > You should not forget one of the two reasons why clean/smudge/diff etc.\n> > drivers must be given with a step of redirection, split between\n> > attributes and config.  \"This path holds text from ancient macs\" at\n> > the logical level may be expressed in .gitattributes, and then \"when\n> > checking out text from ancient macs, process the blob data with this\n> > program to turn it into a form suitable for working tree\" is given as\n> > a smudge filter program, that is (1) suitable for the platform _you_\n> > as the writer of the config file is using *AND* (2) something you are\n> confortable running on behalf of you.\n> >\n> > We *deliberately* lack a mechanism to pay attention to in-tree config\n> > that gets propagated to those who get them via \"git clone\", exactly\n> > because otherwise your upstream may not just specify a \"smudge\"\n> > program that your platform would be unable to run, but can specify a\n> > \"smudge\" program that pretends to be a smudger, but is actually a\n> > program that installs a keylogger and posts your login password and\n> > bank details to this mailing list ;-)\n> >\n> > So, no, I do not think in-tree configuration will fly.\n> \n> I agree, which is why I asked the original question instead of posting it as a\n> formal patch. We would probably get a brand new CVE implementing the\n> proposed proto-changes even if the original intent was internal trusted\n> repositories only. That's why I asked this as a \"Best Practices\" type question,\n> which I think I have a better idea on now. The actual situation is rather cool\n> from a DevOps point of view, and whatever the ultimate solution is, might\n> make for a nice presentation at some future conference 😉.\n\nHere's where I ended up, from a solution standpoint:\n\n0. Make sure the git scripts you use are always trusted using your favourite technique\n1. Wrap the clone in a such a script to do the next two steps to avoid the usual problems of forgetting things\n2. 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\n3. Have the script create/update .git/config using \"git config --local name value\" with all of the same clean/smudge values for subsequent operations.\n\nFrom 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.\n\nSound about right?\n\nCheers,\nRandall\n\n"}]}