Re: General support for ! in git-config values

On 2 February 2012 03:38, Jeff King [off-list ref] wrote:

On Thu, Feb 02, 2012 at 02:57:14AM +0100, demerphq wrote:

quoted

quoted

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/"