{"thread":{"id":"29504","subject":"General support for ! in git-config values","startedAt":"2012-02-01T17:33:47Z","lastAt":"2012-02-03T12:13:52Z","messageCount":20,"participants":["Ævar Arnfjörð Bjarmason","Jeff King","Junio C Hamano","demerphq","Kyle Moffett"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"183487","messageId":"CACBZZX6U+1Fmdaz2ikbbc6zUyF=pMGQOqUGVOWCkUFBUkovCBw@mail.gmail.com","threadId":"29504","inReplyTo":null,"subject":"General support for ! in git-config values","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2012-02-01T17:33:47Z","receivedAt":"2012-02-01T17:33:47Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"alias.* values can start with !, in which case a shell command will be\nexecuted with the arguments you give.\n\nFor a program I'm working on (git-deploy) I'd like to have this as a\ngeneral facility, i.e. users can specify either:\n\n foo.bar = value\n\nOr:\n\n foo.bar = !cat /some/path\n\nI'm wondering why git-config doesn't do this already, if there's no\nreason in particular I can just patch it in, either as a new option:\n\n git config --with-exec --get foo.bar\n\nOr as the default behavior.\n"},{"id":"183490","messageId":"20120201184020.GA29374@sigill.intra.peff.net","threadId":"29504","inReplyTo":"CACBZZX6U+1Fmdaz2ikbbc6zUyF=pMGQOqUGVOWCkUFBUkovCBw@mail.gmail.com","subject":"Re: General support for ! in git-config values","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-01T18:40:20Z","receivedAt":"2012-02-01T18:40:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 01, 2012 at 06:33:47PM +0100, Ævar Arnfjörð Bjarmason wrote:\n\n> For a program I'm working on (git-deploy) I'd like to have this as a\n> general facility, i.e. users can specify either:\n> \n> foo.bar = value\n> \n> Or:\n> \n> foo.bar = !cat /some/path\n> \n> I'm wondering why git-config doesn't do this already, if there's no\n> reason in particular I can just patch it in, either as a new option:\n> \n> git config --with-exec --get foo.bar\n\nI'm not clear on what you want --with-exec to do. By default, config\nvalues are strings. I would expect the \"!\" to be a special marker that\nthe caller would recognize in the string, and then act appropriately.\n\nSo if I were implementing git aliases in the shell, the code would look\nlike:\n\n v=$(git config alias.$alias)\n case \"$v\" in\n \"\")\n die \"no such alias: $alias\" ;;\n \"!*)\n cmd=\"${v#!}\" ;;\n *)\n cmd=\"git $v\" ;;\n esac\n eval \"$cmd\"\n\nI.e., everything pertaining to \"!\" happens after we get the config\nstring. So what is it that you want \"git config --with-exec\" to do?\n\n-Peff\n"},{"id":"183497","messageId":"CACBZZX5mX55Rh8b2GYv7wKbCCypCkrn5AiM9BpXydgcYxHWdQA@mail.gmail.com","threadId":"29504","inReplyTo":"20120201184020.GA29374@sigill.intra.peff.net","subject":"Re: General support for ! in git-config values","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2012-02-01T21:25:31Z","receivedAt":"2012-02-01T21:25:31Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Feb 1, 2012 at 19:40, Jeff King wrote:\n> On Wed, Feb 01, 2012 at 06:33:47PM +0100, Ævar Arnfjörð Bjarmason wrote:\n>\n>> For a program I'm working on (git-deploy) I'd like to have this as a\n>> general facility, i.e. users can specify either:\n>>\n>>     foo.bar = value\n>>\n>> Or:\n>>\n>>     foo.bar = !cat /some/path\n>>\n>> I'm wondering why git-config doesn't do this already, if there's no\n>> reason in particular I can just patch it in, either as a new option:\n>>\n>>     git config --with-exec --get foo.bar\n>\n> I'm not clear on what you want --with-exec to do. By default, config\n> values are strings. I would expect the \"!\" to be a special marker that\n> the caller would recognize in the string, and then act appropriately.\n>\n> So if I were implementing git aliases in the shell, the code would look\n> like:\n>\n>  v=$(git config alias.$alias)\n>  case \"$v\" in\n>  \"\")\n>          die \"no such alias: $alias\" ;;\n>  \"!*)\n>          cmd=\"${v#!}\" ;;\n>  *)\n>          cmd=\"git $v\" ;;\n>  esac\n>  eval \"$cmd\"\n>\n> I.e., everything pertaining to \"!\" happens after we get the config\n> string. So what is it that you want \"git config --with-exec\" to do?\n\nI agree that that's how it should work, I just suggested --with-exec\nin case anyone complained about the backwards compatibility issue of\nchanging the meaning of \"!\" for existing configs.\n"},{"id":"183506","messageId":"7v62fq2o03.fsf@alter.siamese.dyndns.org","threadId":"29504","inReplyTo":"CACBZZX5mX55Rh8b2GYv7wKbCCypCkrn5AiM9BpXydgcYxHWdQA@mail.gmail.com","subject":"Re: General support for ! in git-config values","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-01T22:21:48Z","receivedAt":"2012-02-01T22:21:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n>> I.e., everything pertaining to \"!\" happens after we get the config\n>> string. So what is it that you want \"git config --with-exec\" to do?\n>\n> I agree that that's how it should work, I just suggested --with-exec\n> in case anyone complained about the backwards compatibility issue of\n> changing the meaning of \"!\" for existing configs.\n\nNow you made me utterly confused.\n\nWhat \"backwards compatibility\" issue do you have in mind? If I name\nmyself '!me' with \"user.name = !me\", do I suddenly break backwards\ncompatibility of Git with previous versions somehow? If so how?\n\nThe --with-exec option you talk about seems to me the option about the\nbackward compatibility of the _calling script_ of \"git config\". The old\nversion of git-blorl script may have used foo.bar as a mere string, but a\nnew version of it may (optionally) interpret foo.bar's value in a special\nway when it begins with a \"!\", introducing a backward compatibility issues\nto git-blorl script, and users who want to take advantage of that feature\nmay want to run it as \"git-blorl --with-exec\", and the relevant part of\nthe \"git-blorl\" script might look like this:\n\n\tfoo_bar=$(git config foo.bar)\n case \"$with_exec,$foo_bar\" in\n yes,\\!*)\n \tfoo_bar=$(eval ${foo_bar#\\!}) ;;\n\tesac\n ... then do something interesting using $foo_bar ...\n"},{"id":"183519","messageId":"CANgJU+X+UZmycwE6xkJ-zHfT7ai6nV9zbeR4WYnAXczL5JtqjA@mail.gmail.com","threadId":"29504","inReplyTo":"7v62fq2o03.fsf@alter.siamese.dyndns.org","subject":"Re: General support for ! in git-config values","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-02-02T00:16:38Z","receivedAt":"2012-02-02T00:16:38Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 1 February 2012 23:21, Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason writes:\n>\n>>> I.e., everything pertaining to \"!\" happens after we get the config\n>>> string. So what is it that you want \"git config --with-exec\" to do?\n>>\n>> I agree that that's how it should work, I just suggested --with-exec\n>> in case anyone complained about the backwards compatibility issue of\n>> changing the meaning of \"!\" for existing configs.\n>\n> Now you made me utterly confused.\n>\n> What \"backwards compatibility\" issue do you have in mind?  If I name\n> myself '!me' with \"user.name = !me\", do I suddenly break backwards\n> compatibility of Git with previous versions somehow? If so how?\n\n(I am piping up because Ævar and I discussed this idea earlier today\nwhile we discussed git-deploy)\n\nIf Ævar's proposal was implemented without a --with-exec switch then\n\nuser.name = !me\n\nwould set your name to the result of executing the \"me\" command, which\nlikely would have the same result as not having set your name at all,\nbut presumably with a warning about a bad command.\n\n> The --with-exec option you talk about seems to me the option about the\n> backward compatibility of the _calling script_ of \"git config\".\n\nBy backward compatibility he meant that anything not providing the\n--with-exec option to git-config would continue to behave as before,\nand anything that did would get the new more powerful behavior, where\n! at the front of a value signified that it meant a command to be\nexecuted whose output would be used as the value.\n\nI think it would be convenient to be able to enable this in the config\nfile itself. Consider a bunch of devs share a box. Their full name and\nemail address can be located via a LDAP lookup. So if we could enable\nÆvar's proposal in the config then we can automagically have their\ncommits have the correct username and email if we were to put in the\n/etc/gitconfig something like this:\n\nconfig.enable_executable_options=true\nuser.name=!ldap_full_name\nuser.email=!ldap_email\n\nSo now, user.name and user.email don't have to be configured by the\nusers. They just get an account on the box and all their commits have\nthe right details, no fuss.\n\nI am aware that there are other ways of solving /this/ particular\nproblem, so it specifically is not a big deal, but still I think the\nidea makes a lot of sense, I can imagine it being used in a lot of\ninteresting ways that are not obvious right away.\n\ncheers,\nYves\n\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"183521","messageId":"7vliom13lm.fsf@alter.siamese.dyndns.org","threadId":"29504","inReplyTo":"CANgJU+X+UZmycwE6xkJ-zHfT7ai6nV9zbeR4WYnAXczL5JtqjA@mail.gmail.com","subject":"Re: General support for ! in git-config values","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-02T00:27:49Z","receivedAt":"2012-02-02T00:27:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"demerphq writes:\n\n> If Ævar's proposal was implemented without a --with-exec switch then\n>\n> user.name = !me\n>\n> would set your name to the result of executing the \"me\" command, which\n> likely would have the same result as not having set your name at all,\n> but presumably with a warning about a bad command.\n>\n> user.name=!ldap_full_name\n> user.email=!ldap_email\n\nI didn't get the impression that that was what he was proposing, but\nregardless of who's suggesting it, the above does not make any sense,\nfrom the syntax point of view.\n\nWhen you say \"alias.co = !git checkout --foo-bar\", you are not saying\n\"instead of usual aliases like 'alias.co = checkout' that defines what\nstring replaces the 'co' alias, please run !whatever command, capture\nits output, and that is the _value_ of alias.co variable, i.e. the command\nline that is going to be run\".\n"},{"id":"183526","messageId":"CANgJU+XQWdFmfmBJ4KX4GBz1a=TrVbp9BphGmhEb5Gphmzogjw@mail.gmail.com","threadId":"29504","inReplyTo":"7vliom13lm.fsf@alter.siamese.dyndns.org","subject":"Re: General support for ! in git-config values","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-02-02T01:14:26Z","receivedAt":"2012-02-02T01:14:26Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 2 February 2012 01:27, Junio C Hamano wrote:\n> demerphq writes:\n>\n>> If Ævar's proposal was implemented without a --with-exec switch then\n>>\n>> user.name = !me\n>>\n>> would set your name to the result of executing the \"me\" command, which\n>> likely would have the same result as not having set your name at all,\n>> but presumably with a warning about a bad command.\n>>\n>> user.name=!ldap_full_name\n>> user.email=!ldap_email\n>\n> I didn't get the impression that that was what he was proposing, but\n> regardless of who's suggesting it, the above does not make any sense,\n> from the syntax point of view.\n\nDoes that mean that from a utility point of view it does?\n\nAs for the suggestion and who is making it, this came up because Ævar\nand I were discussing git-deploy and a scenario much like I described,\nwhere we use tags to mark out rollouts and we have multiple users\nusing a common staging server and git repo to do the rollouts from, we\nwant the tags to have proper details, so we have to go through some\nhoops to ensure that users have properly configured things before the\ndo their first rollout. Since Ævar was aware of the \"!\" notation for\naliases and thought it made some kind of sense to reuse the syntax\nelsewhere he decided to see what people thought. I was not aware of\nthe notation until he pointed it out. I don't use git-alias.\n\n> When you say \"alias.co = !git checkout --foo-bar\", you are not saying\n> \"instead of usual aliases like 'alias.co = checkout' that defines what\n> string replaces the 'co' alias, please run !whatever command, capture\n> its output, and that is the _value_ of alias.co variable, i.e. the command\n> line that is going to be run\".\n\nI think I see your point. Using the same \"!\" notation for \"execute\nthis command and exit\" and \"execute this command and use its result as\nthe config value\" might be confusing.\n\nDo you have a suggestion for a better syntax? Backtick quoting perhaps?\n\ncheers,\nyves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"183529","messageId":"7v7h06109t.fsf@alter.siamese.dyndns.org","threadId":"29504","inReplyTo":"CANgJU+XQWdFmfmBJ4KX4GBz1a=TrVbp9BphGmhEb5Gphmzogjw@mail.gmail.com","subject":"Re: General support for ! in git-config values","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-02T01:39:42Z","receivedAt":"2012-02-02T01:39:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"demerphq writes:\n\n> On 2 February 2012 01:27, Junio C Hamano wrote:\n>> demerphq writes:\n>>\n>>> user.name=!ldap_full_name\n>>> user.email=!ldap_email\n>>\n>> I didn't get the impression that that was what he was proposing, but\n>> regardless of who's suggesting it, the above does not make any sense,\n>> from the syntax point of view.\n>\n> Does that mean that from a utility point of view it does?\n\nNot really.\n\nI do not think whatever \"utility\" value outweighs the hassle of having to\nthink through the ramifications (including but not limited to security) of\nrunning arbitrary user command every time a value is looked up.\n"},{"id":"183530","messageId":"7v39au1073.fsf@alter.siamese.dyndns.org","threadId":"29504","inReplyTo":"CANgJU+XQWdFmfmBJ4KX4GBz1a=TrVbp9BphGmhEb5Gphmzogjw@mail.gmail.com","subject":"Re: General support for ! in git-config values","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-02T01:41:20Z","receivedAt":"2012-02-02T01:41:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"demerphq writes:\n\n>> When you say \"alias.co = !git checkout --foo-bar\", you are not saying\n>> \"instead of usual aliases like 'alias.co = checkout' that defines what\n>> string replaces the 'co' alias, please run !whatever command, capture\n>> its output, and that is the _value_ of alias.co variable, i.e. the command\n>> line that is going to be run\".\n>\n> I think I see your point. Using the same \"!\" notation for \"execute\n> this command and exit\" and \"execute this command and use its result as\n> the config value\" might be confusing.\n\nI am afraid that you are not seeing it. In \"alias.co = !whatever\", bang\ndoes *NOT* mean \"execute this command and exit\".\n"},{"id":"183533","messageId":"CANgJU+WCdsF+igCWoueYcChYBvNyj5je_kvWorCBOgh5D7Bb9g@mail.gmail.com","threadId":"29504","inReplyTo":"7v7h06109t.fsf@alter.siamese.dyndns.org","subject":"Re: General support for ! in git-config values","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-02-02T01:57:14Z","receivedAt":"2012-02-02T01:57:14Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 2 February 2012 02:39, Junio C Hamano wrote:\n> demerphq writes:\n>\n>> On 2 February 2012 01:27, Junio C Hamano wrote:\n>>> demerphq writes:\n>>>\n>>>> user.name=!ldap_full_name\n>>>> user.email=!ldap_email\n>>>\n>>> I didn't get the impression that that was what he was proposing, but\n>>> regardless of who's suggesting it, the above does not make any sense,\n>>> from the syntax point of view.\n>>\n>> Does that mean that from a utility point of view it does?\n>\n> Not really.\n>\n> I do not think whatever \"utility\" value outweighs the hassle of having to\n> think through the ramifications (including but not limited to security) of\n> running arbitrary user command every time a value is looked up.\n\nWhy is that your problem? If I have to enable it then isn't that my choice?\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"183536","messageId":"CANgJU+VKgYVnjABVi-cNS6MBsAAEDeOzcHoB1MFJmhC3i=8++Q@mail.gmail.com","threadId":"29504","inReplyTo":"7v39au1073.fsf@alter.siamese.dyndns.org","subject":"Re: General support for ! in git-config values","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-02-02T02:06:34Z","receivedAt":"2012-02-02T02:06:34Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 2 February 2012 02:41, Junio C Hamano wrote:\n> demerphq writes:\n>\n>>> When you say \"alias.co = !git checkout --foo-bar\", you are not saying\n>>> \"instead of usual aliases like 'alias.co = checkout' that defines what\n>>> string replaces the 'co' alias, please run !whatever command, capture\n>>> its output, and that is the _value_ of alias.co variable, i.e. the command\n>>> line that is going to be run\".\n>>\n>> I think I see your point. Using the same \"!\" notation for \"execute\n>> this command and exit\" and \"execute this command and use its result as\n>> the config value\" might be confusing.\n>\n> I am afraid that you are not seeing it.  In \"alias.co = !whatever\", bang\n> does *NOT* mean \"execute this command and exit\".\n\nThen I have been unclear. I understand what this does:\n\n$ git config alias.foo '!echo foo'\n$ git foo\nfoo\n\nAnd if you were trying to say that having \"!\" denote \"execute this\ncommand and use its return as the config value\" would be confusing as\nit is different from its meaning for aliases then I see your point.\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"183537","messageId":"20120202023857.GA11745@sigill.intra.peff.net","threadId":"29504","inReplyTo":"CANgJU+WCdsF+igCWoueYcChYBvNyj5je_kvWorCBOgh5D7Bb9g@mail.gmail.com","subject":"Re: General support for ! in git-config values","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-02T02:38:57Z","receivedAt":"2012-02-02T02:38:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 02, 2012 at 02:57:14AM +0100, demerphq wrote:\n\n> > Not really.\n> >\n> > I do not think whatever \"utility\" value outweighs the hassle of having to\n> > think through the ramifications (including but not limited to security) of\n> > running arbitrary user command every time a value is looked up.\n> \n> Why is that your problem? If I have to enable it then isn't that my choice?\n\n>From a security perspective, you want to make sure that people who\naren't interested in your feature don't accidentally trigger it. E.g.,\nimagine I currently run a locked-down git repo but execute some commands\non your behalf, and I allow you to set a few \"known safe\" config options\nlike user.email. Even though I am not interested in your feature,\nrespecting \"!rm -rf /\" in the user.email you give me would be a bad\nthing.\n\nIt's not an insurmountable problem. There could be options to turn it\non, or turn it off, or whatever. Or we could shrug and say that config\nis already dangerous to let other people set (which it is already, but\nonly for some options). But those are the sorts of ramifications that\nneed to be thought through.\n\n(Another one is that with our current strategy, we actually read and\nparse the config files multiple times. Should your program get run many\ntimes?).\n\n-Peff\n"},{"id":"183568","messageId":"CANgJU+X2dRP__PFAywGEisDS3xyF7fSszSQG6BO61j2TMKL3Qg@mail.gmail.com","threadId":"29504","inReplyTo":"20120202023857.GA11745@sigill.intra.peff.net","subject":"Re: General support for ! in git-config values","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-02-02T09:44:05Z","receivedAt":"2012-02-02T09:44:05Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 2 February 2012 03:38, Jeff King wrote:\n> On Thu, Feb 02, 2012 at 02:57:14AM +0100, demerphq wrote:\n>\n>> > Not really.\n>> >\n>> > I do not think whatever \"utility\" value outweighs the hassle of having to\n>> > think through the ramifications (including but not limited to security) of\n>> > running arbitrary user command every time a value is looked up.\n>>\n>> Why is that your problem? If I have to enable it then isn't that my choice?\n>\n> From a security perspective, you want to make sure that people who\n> aren't interested in your feature don't accidentally trigger it. E.g.,\n> imagine I currently run a locked-down git repo but execute some commands\n> on your behalf, and I allow you to set a few \"known safe\" config options\n> like user.email. Even though I am not interested in your feature,\n> respecting \"!rm -rf /\" in the user.email you give me would be a bad\n> thing.\n\nLike I said, I do not think this should be enabled by default, I think\nit should be possible to enable it config wide. So unless this\nscenario involves getting the owner of the locked down repo to enable\na config option they know nothing about, in which case I would say\nthere are easier attacks -- someone that stupid probably could be\ntalked into telling you their root password. :-)\n\n> It's not an insurmountable problem. There could be options to turn it\n> on, or turn it off, or whatever.\n\nMy thought exactly. Anyone paranoid about security would never enable\nthis feature. Those who are comfortable with the security issues\ncould.\n\n> Or we could shrug and say that config\n> is already dangerous to let other people set (which it is already, but\n> only for some options).\n\nI think that since it could be set up to be determined by the user,\nthat it would be no more dangerous than any other option.\n\n> But those are the sorts of ramifications that\n> need to be thought through.\n\nI understand that. All I can say is $work uses git on a pretty large\nscale, 100+ devs etc, and we use it to manage our rollout processes\nwhich we use a lot (I cant say how often but a lot). So if it would be\nuseful to us it probably would be useful to others.\n\n> (Another one is that with our current strategy, we actually read and\n> parse the config files multiple times. Should your program get run many\n> times?).\n\nAgain I would say this is not git's problem. If it should not be run\nmultiple times it is up to the user to figure out an alternative.\n\nThe general design of git seems to me to be based around providing\nbuilding blocks that people can use to build new and interesting tools\non top of, and so it seems counter to that philosophy to reject an\nfeature based on speculative security issues that really can't be\ndecided in advance but must instead be decided on a case by case\nbasis.\n\ncheers,\nYves\n\n\n\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"183570","messageId":"20120202095432.GA19356@sigill.intra.peff.net","threadId":"29504","inReplyTo":"CANgJU+X2dRP__PFAywGEisDS3xyF7fSszSQG6BO61j2TMKL3Qg@mail.gmail.com","subject":"Re: General support for ! in git-config values","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-02T09:54:32Z","receivedAt":"2012-02-02T09:54:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 02, 2012 at 10:44:05AM +0100, demerphq wrote:\n\n> The general design of git seems to me to be based around providing\n> building blocks that people can use to build new and interesting tools\n> on top of, and so it seems counter to that philosophy to reject an\n> feature based on speculative security issues that really can't be\n> decided in advance but must instead be decided on a case by case\n> basis.\n\nI can't speak for Junio, but I am certainly not rejecting it. Only\nsaying that it needs to be thought through, and the utility weighed\nagainst the costs. So far I haven't seen an actual patch to comment on\n(or even a proposed syntax beyond starting a string with \"!\", which I\nthink is a non-starter due to conflicting with existing uses), nor have\nI seen a concrete use case (you mentioned pulling the name/email from\nldap, but you also mentioned that there are lots of other ways of\nsolving that particular problem, so it's not especially compelling).\n\nI'd be happy to hear a more concrete proposal.\n\n-Peff\n"},{"id":"183575","messageId":"CANgJU+XoZd6x6jdSHszigZaPgi+6H3Nbf4OG7p0y1_=7m+qntA@mail.gmail.com","threadId":"29504","inReplyTo":"20120202095432.GA19356@sigill.intra.peff.net","subject":"Re: General support for ! in git-config values","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-02-02T10:21:54Z","receivedAt":"2012-02-02T10:21:54Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 2 February 2012 10:54, Jeff King wrote:\n> On Thu, Feb 02, 2012 at 10:44:05AM +0100, demerphq wrote:\n>\n>> The general design of git seems to me to be based around providing\n>> building blocks that people can use to build new and interesting tools\n>> on top of, and so it seems counter to that philosophy to reject an\n>> feature based on speculative security issues that really can't be\n>> decided in advance but must instead be decided on a case by case\n>> basis.\n>\n> I can't speak for Junio, but I am certainly not rejecting it. Only\n> saying that it needs to be thought through, and the utility weighed\n> against the costs.\n\nOf course. I totally understand. I have written mails saying stuff\nlike this myself. :-)\n\n> So far I haven't seen an actual patch to comment on\n> (or even a proposed syntax beyond starting a string with \"!\", which I\n> think is a non-starter due to conflicting with existing uses),\n\nI understand. I think we will probably use backtick quoting in git-deploy. So\n\ndeploy.prefix=`cat /etc/SERVER_ROLE`\n\nwill execute cat /etc/SERVER_ROLE and use the results as the value of\nthe config option.\n\n> nor have\n> I seen a concrete use case (you mentioned pulling the name/email from\n> ldap, but you also mentioned that there are lots of other ways of\n> solving that particular problem, so it's not especially compelling).\n\nOne place that it would be useful for us in git-deploy would be to\ndetect the tag prefix for the rollout we are doing. Every staging\nserver already has a file that contains this value. We would like to\nmake it easy for people to configure the tool to either use the value\nprovided, or to use something like `cat /etc/SERVER_ROLE` instead.\nAnyway, from that POV I could totally understand \"so do that in\ngit-deploy\". Since the tool is written in perl we have to wrap\ngit-config anyway, so it easy to add a special case for ourselves.\n\nBut I still think the general idea is pretty useful, the ldap example\nis IMO a cleaner solution than the alternatives, and a variant that I\nthink is much harder to do currently come to mind right away: setting\nthe user.email automatically depending on where in your tree a git\nrepo was located, so that when I work on repo underneath /CPAN/ it\nuses my CPAN address, and when I work in my /work/ tree it uses my\n$work address, etc, without me having to configure it repo by repo.\n(This has bitten more than once in the past)\n\n> I'd be happy to hear a more concrete proposal.\n\nI will be mostly afk the next week so I will leave that to Avar if he\nwants to pursue it.\n\ncheers,\nYves\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"183695","messageId":"CAGZ=bq++R+X+2r2_zQ4UZ6JvDC9W9_4nF23MQ6+612_Qe2RS4Q@mail.gmail.com","threadId":"29504","inReplyTo":"CANgJU+XoZd6x6jdSHszigZaPgi+6H3Nbf4OG7p0y1_=7m+qntA@mail.gmail.com","subject":"Re: General support for ! in git-config values","fromName":"Kyle Moffett","fromEmail":"kyle@moffetthome.net","sentAt":"2012-02-03T05:08:46Z","receivedAt":"2012-02-03T05:08:46Z","isPatch":false,"sender":{"key":"kyle@moffetthome.net","avatar":null},"body":"On Thu, Feb 2, 2012 at 02:21, demerphq wrote:\n>> So far I haven't seen an actual patch to comment on\n>> (or even a proposed syntax beyond starting a string with \"!\", which I\n>> think is a non-starter due to conflicting with existing uses),\n>\n> I understand. I think we will probably use backtick quoting in git-deploy. So\n>\n> deploy.prefix=`cat /etc/SERVER_ROLE`\n>\n> will execute cat /etc/SERVER_ROLE and use the results as the value of\n> the config option.\n\nAlternatively, you could extend the recent proposal for GIT config\n\"include\" statements so that something like this works:\n\n[include]\n exec = echo \"deploy.prefix = `cat /etc/SERVER_ROLE`\"\n exec = /usr/local/bin/git-config-for-ldap-user\n\nThoughts?\n\nCheers,\nKyle Moffett\n"},{"id":"183698","messageId":"7vmx90say8.fsf@alter.siamese.dyndns.org","threadId":"29504","inReplyTo":"CAGZ=bq++R+X+2r2_zQ4UZ6JvDC9W9_4nF23MQ6+612_Qe2RS4Q@mail.gmail.com","subject":"Re: General support for ! in git-config values","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-03T06:11:27Z","receivedAt":"2012-02-03T06:11:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kyle Moffett writes:\n\n> Alternatively, you could extend the recent proposal for GIT config\n> \"include\" statements so that something like this works:\n>\n> [include]\n> exec = echo \"deploy.prefix = `cat /etc/SERVER_ROLE`\"\n> exec = /usr/local/bin/git-config-for-ldap-user\n\nErh...\n\nRunning known stuff from your own .git/config may be justifiable as \"at\nyour own risk\", but if we consider sources that are not under your direct\ncontrol, such as /etc/gitconfig and whatever your project encourages you\nto include from your .git/config,... eek.\n"},{"id":"183699","messageId":"CAGZ=bq+i6t7ik6WoX8B=_uKR6WVvnBk3KuJDngFpWObGWgivzw@mail.gmail.com","threadId":"29504","inReplyTo":"7vmx90say8.fsf@alter.siamese.dyndns.org","subject":"Re: General support for ! in git-config values","fromName":"Kyle Moffett","fromEmail":"kyle@moffetthome.net","sentAt":"2012-02-03T07:35:14Z","receivedAt":"2012-02-03T07:35:14Z","isPatch":false,"sender":{"key":"kyle@moffetthome.net","avatar":null},"body":"On Thu, Feb 2, 2012 at 22:11, Junio C Hamano wrote:\n> Kyle Moffett writes:\n>\n>> Alternatively, you could extend the recent proposal for GIT config\n>> \"include\" statements so that something like this works:\n>>\n>> [include]\n>>     exec = echo \"deploy.prefix = `cat /etc/SERVER_ROLE`\"\n>>     exec = /usr/local/bin/git-config-for-ldap-user\n>\n> Erh...\n>\n> Running known stuff from your own .git/config may be justifiable as \"at\n> your own risk\", but if we consider sources that are not under your direct\n> control, such as /etc/gitconfig and whatever your project encourages you\n> to include from your .git/config,... eek.\n\nWell yes, but running commands from .git/config is exactly what the OP\nrequested, and if it applies to .git/config it should also be\napplicable to other trusted include sources too, no?\n\nPerhaps allow config files to perform a \"trusted\" include, EG:\n[include]\n trusted_exec = /usr/local/bin/site-specific-config-program\n blob = v1.0:src/gitconfig\n\nBy default, the only files which would be trusted are /etc/gitconfig,\n~/.gitconfig, and .git/config (but ONLY if it has the same owner and\nmode go-w), and they would only pass trust on to other files if they\nuse \"trusted_*\" include lines.\n\nAlso, since \"include\" is intended to introduce a\nnon-backwards-compatible change in behavior, perhaps a totally\ndifferent format should be used, EG:\n\n$include exec_trusted /usr/local/bin/site-specific-config-program\n$include blob v1.0:src/gitconfig\n\nSomething that would cause noticeable warnings in older versions of\ngit instead of silently ignoring the desired config includes.\n\nJust a few thoughts.\n\nCheers,\nKyle Moffett\n"},{"id":"183709","messageId":"20120203120936.GC31441@sigill.intra.peff.net","threadId":"29504","inReplyTo":"CAGZ=bq++R+X+2r2_zQ4UZ6JvDC9W9_4nF23MQ6+612_Qe2RS4Q@mail.gmail.com","subject":"Re: General support for ! in git-config values","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-03T12:09:36Z","receivedAt":"2012-02-03T12:09:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 02, 2012 at 09:08:46PM -0800, Kyle Moffett wrote:\n\n> > I understand. I think we will probably use backtick quoting in git-deploy. So\n> >\n> > deploy.prefix=`cat /etc/SERVER_ROLE`\n> >\n> > will execute cat /etc/SERVER_ROLE and use the results as the value of\n> > the config option.\n> \n> Alternatively, you could extend the recent proposal for GIT config\n> \"include\" statements so that something like this works:\n> \n> [include]\n> exec = echo \"deploy.prefix = `cat /etc/SERVER_ROLE`\"\n> exec = /usr/local/bin/git-config-for-ldap-user\n> \n> Thoughts?\n\nI am still undecided on whether the utility of the idea is worth the\npotential hassle, but syntactically I like that better. It does put a\nlittle more burden on the called program to handle things like quoting,\nthough.\n\n-Peff\n"},{"id":"183710","messageId":"20120203121352.GD31441@sigill.intra.peff.net","threadId":"29504","inReplyTo":"7vmx90say8.fsf@alter.siamese.dyndns.org","subject":"Re: General support for ! in git-config values","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-03T12:13:52Z","receivedAt":"2012-02-03T12:13:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 02, 2012 at 10:11:27PM -0800, Junio C Hamano wrote:\n\n> Kyle Moffett writes:\n> \n> > Alternatively, you could extend the recent proposal for GIT config\n> > \"include\" statements so that something like this works:\n> >\n> > [include]\n> > exec = echo \"deploy.prefix = `cat /etc/SERVER_ROLE`\"\n> > exec = /usr/local/bin/git-config-for-ldap-user\n> \n> Erh...\n> \n> Running known stuff from your own .git/config may be justifiable as \"at\n> your own risk\", but if we consider sources that are not under your direct\n> control, such as /etc/gitconfig and whatever your project encourages you\n> to include from your .git/config,... eek.\n\nFor normal use, I don't see this as a big deal. They could also be\nspecifying diff.external, which would run arbitrary code (and who\ndoesn't run \"git diff\" once in a while?).\n\nI see it as a bigger issue for sites which serve repositories on behalf\nof their users, and already take care never to use porcelain commands\nwhich will run arbitrary code from the config by default (e.g., gitweb\ncarefully uses diff plumbing for this reason). Introducing such an\noption provides a mechanism for users who control the config of the\nserved repositories to execute code as the user running git-daemon or\ngitweb.\n\n-Peff\n"}]}