From: Jeff King <firstname.lastname@example.org> To: Alex Riesen <email@example.com> Cc: Junio C Hamano <firstname.lastname@example.org>, email@example.com, Christian Couder <firstname.lastname@example.org>, Jonathan Nieder <email@example.com> Subject: Re: "git -c web.browser=w3m help -w help" still kicks firefox Date: Mon, 23 Aug 2010 16:33:04 -0400 [thread overview] Message-ID: <20100823203304.GB4458@coredump.intra.peff.net> (raw) In-Reply-To: <AANLkTi=R6ZdD9GUO6T6uCUkF+KVPbG1FGrieOfeusKct@mail.gmail.com> On Mon, Aug 23, 2010 at 09:02:36PM +0200, Alex Riesen wrote: > Maybe it is worth fixing, but on a case-by-case basis? > > I mean changing the execv_git_cmd interface (or create a new execv > function), so that it can get the list of config vars to pass down to > the callee. A trivial case of its use would be to just pass the > current config (or, more likely, none). Or, one could give it its own > list of config parameters. I don't think that is enough. We don't necessarily know which config options will be relevant to exec'd processes. We could be running some user-defined command that calls a bunch of other git commands. Or a hook, for that matter. Which does bring up one interesting boundary. If I run: git -c receive.denyDeletes=false git push what should happen? Obviously with cross-server communication the environment won't get passed. I am inclined to say that even for local cases, receive-pack should clear the string. Certainly for the sake of consistency between local and remote transports, but it may also be a security issue (in most cases, no, since you would have to be exec'ing receive-pack directly, and you are clearly already running an arbitrary command, but I can see somebody perhaps crossing a setuid boundary with receive-pack). -Peff
next prev parent reply other threads:[~2010-08-23 20:33 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-08-23 18:05 Junio C Hamano 2010-08-23 18:38 ` Jeff King 2010-08-23 19:16 ` Jeff King 2010-08-24 6:41 ` [PATCH 2/1] do not pass "git -c foo=bar" params to transport helpers Jonathan Nieder 2010-08-24 14:14 ` Jeff King 2010-08-24 19:07 ` [PATCH 2/1] do not pass "git -c foo=bar" " Eric Raible 2010-08-23 19:02 ` "git -c web.browser=w3m help -w help" still kicks firefox Alex Riesen 2010-08-23 20:33 ` Jeff King [this message] 2010-08-24 5:01 ` Jonathan Nieder 2010-08-24 14:12 ` Jeff King
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20100823203304.GB4458@coredump.intra.peff.net \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: "git -c web.browser=w3m help -w help" still kicks firefox' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.