Kyle Moffett [off-list ref] writes:
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
Erh...
Running known stuff from your own .git/config may be justifiable as "at
your own risk", but if we consider sources that are not under your direct
control, such as /etc/gitconfig and whatever your project encourages you
to include from your .git/config,... eek.
On Thu, Feb 2, 2012 at 22:11, Junio C Hamano [off-list ref] wrote:
Kyle Moffett [off-list ref] writes:
quoted
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
Erh...
Running known stuff from your own .git/config may be justifiable as "at
your own risk", but if we consider sources that are not under your direct
control, such as /etc/gitconfig and whatever your project encourages you
to include from your .git/config,... eek.
Well yes, but running commands from .git/config is exactly what the OP
requested, and if it applies to .git/config it should also be
applicable to other trusted include sources too, no?
Perhaps allow config files to perform a "trusted" include, EG:
[include]
trusted_exec = /usr/local/bin/site-specific-config-program
blob = v1.0:src/gitconfig
By default, the only files which would be trusted are /etc/gitconfig,
~/.gitconfig, and .git/config (but ONLY if it has the same owner and
mode go-w), and they would only pass trust on to other files if they
use "trusted_*" include lines.
Also, since "include" is intended to introduce a
non-backwards-compatible change in behavior, perhaps a totally
different format should be used, EG:
$include exec_trusted /usr/local/bin/site-specific-config-program
$include blob v1.0:src/gitconfig
Something that would cause noticeable warnings in older versions of
git instead of silently ignoring the desired config includes.
Just a few thoughts.
Cheers,
Kyle Moffett
On Thu, Feb 02, 2012 at 10:11:27PM -0800, Junio C Hamano wrote:
Kyle Moffett [off-list ref] writes:
quoted
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
Erh...
Running known stuff from your own .git/config may be justifiable as "at
your own risk", but if we consider sources that are not under your direct
control, such as /etc/gitconfig and whatever your project encourages you
to include from your .git/config,... eek.
For normal use, I don't see this as a big deal. They could also be
specifying diff.external, which would run arbitrary code (and who
doesn't run "git diff" once in a while?).
I see it as a bigger issue for sites which serve repositories on behalf
of their users, and already take care never to use porcelain commands
which will run arbitrary code from the config by default (e.g., gitweb
carefully uses diff plumbing for this reason). Introducing such an
option provides a mechanism for users who control the config of the
served repositories to execute code as the user running git-daemon or
gitweb.
-Peff