From: Junio C Hamano <hidden> Date: 2016-06-15 22:52:54
demerphq [off-list ref] writes:
On 2 February 2012 01:27, Junio C Hamano [off-list ref] wrote:
quoted
demerphq [off-list ref] writes:
quoted
user.name=!ldap_full_name
user.email=!ldap_email
I didn't get the impression that that was what he was proposing, but
regardless of who's suggesting it, the above does not make any sense,
from the syntax point of view.
Does that mean that from a utility point of view it does?
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.
On 2 February 2012 02:39, Junio C Hamano [off-list ref] wrote:
demerphq [off-list ref] writes:
quoted
On 2 February 2012 01:27, Junio C Hamano [off-list ref] wrote:
quoted
demerphq [off-list ref] writes:
quoted
user.name=!ldap_full_name
user.email=!ldap_email
I didn't get the impression that that was what he was proposing, but
regardless of who's suggesting it, the above does not make any sense,
from the syntax point of view.
Does that mean that from a utility point of view it does?
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?
--
perl -Mre=debug -e "/just|another|perl|hacker/"
From: Jeff King <hidden> Date: 2016-06-15 22:52:54
On Thu, Feb 02, 2012 at 02:57:14AM +0100, demerphq wrote:
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.
It's not an insurmountable problem. There could be options to turn it
on, or turn it off, or whatever. 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). But those are the sorts of ramifications that
need to be thought through.
(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?).
-Peff
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/"
From: Jeff King <hidden> Date: 2016-06-15 22:52:55
On Thu, Feb 02, 2012 at 10:44:05AM +0100, demerphq wrote:
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.
I can't speak for Junio, but I am certainly not rejecting it. Only
saying that it needs to be thought through, and the utility weighed
against the costs. So far I haven't seen an actual patch to comment on
(or even a proposed syntax beyond starting a string with "!", which I
think is a non-starter due to conflicting with existing uses), nor have
I seen a concrete use case (you mentioned pulling the name/email from
ldap, but you also mentioned that there are lots of other ways of
solving that particular problem, so it's not especially compelling).
I'd be happy to hear a more concrete proposal.
-Peff
On 2 February 2012 10:54, Jeff King [off-list ref] wrote:
On Thu, Feb 02, 2012 at 10:44:05AM +0100, demerphq wrote:
quoted
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.
I can't speak for Junio, but I am certainly not rejecting it. Only
saying that it needs to be thought through, and the utility weighed
against the costs.
Of course. I totally understand. I have written mails saying stuff
like this myself. :-)
So far I haven't seen an actual patch to comment on
(or even a proposed syntax beyond starting a string with "!", which I
think is a non-starter due to conflicting with existing uses),
I understand. I think we will probably use backtick quoting in git-deploy. So
deploy.prefix=`cat /etc/SERVER_ROLE`
will execute cat /etc/SERVER_ROLE and use the results as the value of
the config option.
nor have
I seen a concrete use case (you mentioned pulling the name/email from
ldap, but you also mentioned that there are lots of other ways of
solving that particular problem, so it's not especially compelling).
One place that it would be useful for us in git-deploy would be to
detect the tag prefix for the rollout we are doing. Every staging
server already has a file that contains this value. We would like to
make it easy for people to configure the tool to either use the value
provided, or to use something like `cat /etc/SERVER_ROLE` instead.
Anyway, from that POV I could totally understand "so do that in
git-deploy". Since the tool is written in perl we have to wrap
git-config anyway, so it easy to add a special case for ourselves.
But I still think the general idea is pretty useful, the ldap example
is IMO a cleaner solution than the alternatives, and a variant that I
think is much harder to do currently come to mind right away: setting
the user.email automatically depending on where in your tree a git
repo was located, so that when I work on repo underneath /CPAN/ it
uses my CPAN address, and when I work in my /work/ tree it uses my
$work address, etc, without me having to configure it repo by repo.
(This has bitten more than once in the past)
I'd be happy to hear a more concrete proposal.
I will be mostly afk the next week so I will leave that to Avar if he
wants to pursue it.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
On Thu, Feb 2, 2012 at 02:21, demerphq [off-list ref] wrote:
quoted
So far I haven't seen an actual patch to comment on
(or even a proposed syntax beyond starting a string with "!", which I
think is a non-starter due to conflicting with existing uses),
I understand. I think we will probably use backtick quoting in git-deploy. So
deploy.prefix=`cat /etc/SERVER_ROLE`
will execute cat /etc/SERVER_ROLE and use the results as the value of
the config option.
Alternatively, you could extend the recent proposal for GIT config
"include" statements so that something like this works:
[include]
exec = echo "deploy.prefix = `cat /etc/SERVER_ROLE`"
exec = /usr/local/bin/git-config-for-ldap-user
Thoughts?
Cheers,
Kyle Moffett
From: Jeff King <hidden> Date: 2016-06-15 22:52:55
On Thu, Feb 02, 2012 at 09:08:46PM -0800, Kyle Moffett wrote:
quoted
I understand. I think we will probably use backtick quoting in git-deploy. So
deploy.prefix=`cat /etc/SERVER_ROLE`
will execute cat /etc/SERVER_ROLE and use the results as the value of
the config option.
Alternatively, you could extend the recent proposal for GIT config
"include" statements so that something like this works:
[include]
exec = echo "deploy.prefix = `cat /etc/SERVER_ROLE`"
exec = /usr/local/bin/git-config-for-ldap-user
Thoughts?
I am still undecided on whether the utility of the idea is worth the
potential hassle, but syntactically I like that better. It does put a
little more burden on the called program to handle things like quoting,
though.
-Peff