On 2 February 2012 03:38, Jeff King <peff@xxxxxxxx> wrote: > On Thu, Feb 02, 2012 at 02:57:14AM +0100, demerphq wrote: > >> > Not really. >> > >> > I do not think whatever "utility" value outweighs the hassle of having to >> > think through the ramifications (including but not limited to security) of >> > running arbitrary user command every time a value is looked up. >> >> Why is that your problem? If I have to enable it then isn't that my choice? > > From a security perspective, you want to make sure that people who > aren't interested in your feature don't accidentally trigger it. E.g., > imagine I currently run a locked-down git repo but execute some commands > on your behalf, and I allow you to set a few "known safe" config options > like user.email. Even though I am not interested in your feature, > respecting "!rm -rf /" in the user.email you give me would be a bad > thing. Like I said, I do not think this should be enabled by default, I think it should be possible to enable it config wide. So unless this scenario involves getting the owner of the locked down repo to enable a config option they know nothing about, in which case I would say there are easier attacks -- someone that stupid probably could be talked into telling you their root password. :-) > It's not an insurmountable problem. There could be options to turn it > on, or turn it off, or whatever. My thought exactly. Anyone paranoid about security would never enable this feature. Those who are comfortable with the security issues could. > Or we could shrug and say that config > is already dangerous to let other people set (which it is already, but > only for some options). I think that since it could be set up to be determined by the user, that it would be no more dangerous than any other option. > But those are the sorts of ramifications that > need to be thought through. I understand that. All I can say is $work uses git on a pretty large scale, 100+ devs etc, and we use it to manage our rollout processes which we use a lot (I cant say how often but a lot). So if it would be useful to us it probably would be useful to others. > (Another one is that with our current strategy, we actually read and > parse the config files multiple times. Should your program get run many > times?). Again I would say this is not git's problem. If it should not be run multiple times it is up to the user to figure out an alternative. The general design of git seems to me to be based around providing building blocks that people can use to build new and interesting tools on top of, and so it seems counter to that philosophy to reject an feature based on speculative security issues that really can't be decided in advance but must instead be decided on a case by case basis. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html