list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Patrick Steinhardt <>
To: Jeff King <>
Cc: "Junio C Hamano" <>,
	"Ævar Arnfjörð Bjarmason" <>,
Subject: Re: [PATCH 2/2] config: allow specifying config entries via envvar pairs
Date: Tue, 17 Nov 2020 07:37:34 +0100	[thread overview]
Message-ID: <X7NvrmisOs4g036W@ncase> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 3490 bytes --]

On Mon, Nov 16, 2020 at 09:34:54PM -0500, Jeff King wrote:
> On Mon, Nov 16, 2020 at 11:39:35AM -0800, Junio C Hamano wrote:
> > >> While not document, it is currently possible to specify config entries
> > [...]
> >
> > "While not documented" yes, for sure, but we do not document it for
> > a good reason---it is a pure implementation detail between Git
> > process that runs another one as its internal implementation detail.
> I have actually been quite tempted to document and promise that it will
> continue to work. Because it really is useful in some instances. The
> thing that has held me back is that the documentation would reveal how
> unforgiving the parser is. ;)
> It insists that key/value pairs are shell-quoted as a whole. I think if
> we made it accept a some reasonable inputs:
>   - do not require quoting for values that do not need it
>   - allow any amount of shell-style single-quoting (whole parameters,
>     just values, etc).
>   - do not bother allowing other quoting, like double-quotes with
>     backslashes. However, document backslash and double-quote as
>     meta-characters that must not appear outside of single-quotes, to
>     allow for future expansion.
> then I'd feel comfortable making it a public-facing feature. And for
> most cases it would be pretty pleasant to use (and for the unpleasant
> ones, I'm not sure that a little quoting is any worse than the paired
> environment variables found here).

I tend to disagree there. As long as you control keys and values
yourself it's not too hard, that's true. But as soon as you start
processing untrusted keys or values, then it's getting a lot harder.

E.g. suppose you create a fetch mirror for a user, where the source is
protected by a password. We don't want to write the password into the
gitconfig of the mirror repository. Passing it via `-C` will show up in
ps(1). Using GIT_CONFIG_PARAMETERS requires you to quote the value,
which contains arbitrary data, and if you fail to do that correctly you
now have an avenue for arbitrary config injection.

That scenario is roughly why I came up with the _KEY/_VALUE schema. It
requires no quoting, is trivial to set up (at least for its target
audience, which is mostly scripts or programs) and wouldn't show up in

> > I especially do not think we want to read from unbounded number of
> > GIT_CONFIG_KEY_<N> variables like this patch does.  How would a
> > script cleanse its environment to protect itself from stray such
> > environment variable pair?  Count up from 1 to forever?  Run "env"
> > and grep for "GIT_CONFIG_KEY_[0-9]*=" (the answer is No.  What if
> > some environment variables have newline in its values?)
> Yeah, scripts can currently assume that:
>   unset $(git rev-parse --local-env-vars)
> will drop any config from the environment. In some cases, having
> rev-parse enumerate the GIT_CONFIG_KEY_* variables that are set would be
> sufficient. But that implies that rev-parse is seeing the same
> environment we're planning to clear. As it is now, a script is free to
> use rev-parse to generate that list, hold on to it, and then use it
> later.

Good point. Adjusting it would be trivial, though: unset all consecutive
GIT_CONFIG_KEY_$n keys and potentially also GIT_CONFIG_VALUE_$n until we
hit a gap. The parser would stop on the first gap anyway.


> -Peff

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-11-17  6:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13 12:16 [PATCH 0/2] " Patrick Steinhardt
2020-11-13 12:16 ` [PATCH 1/2] config: extract function to parse config pairs Patrick Steinhardt
2020-11-13 12:16 ` [PATCH 2/2] config: allow specifying config entries via envvar pairs Patrick Steinhardt
2020-11-13 13:04   ` Ævar Arnfjörð Bjarmason
2020-11-16 19:39     ` Junio C Hamano
2020-11-17  2:34       ` Jeff King
2020-11-17  6:37         ` Patrick Steinhardt [this message]
2020-11-17  7:01           ` Jeff King
2020-11-17 14:22         ` Ævar Arnfjörð Bjarmason
2020-11-17 23:57           ` Jeff King
2020-11-18 13:44             ` Ævar Arnfjörð Bjarmason
2020-11-18  0:50         ` brian m. carlson
2020-11-18  1:59           ` Jeff King
2020-11-18  2:25             ` brian m. carlson
2020-11-18  7:04               ` Patrick Steinhardt
2020-11-19  2:11                 ` brian m. carlson
2020-11-19  6:37                   ` Patrick Steinhardt
2020-11-18  5:44           ` Junio C Hamano
2020-11-17  6:28       ` Patrick Steinhardt
2020-11-17  7:06         ` Junio C Hamano
2020-11-18 13:49           ` Ævar Arnfjörð Bjarmason
2020-11-18 13:56             ` Patrick Steinhardt
2020-11-18 16:01             ` Junio C Hamano
2020-11-17 14:03       ` Ævar Arnfjörð Bjarmason
2020-11-13 16:37   ` Philip Oakley
2020-11-17  6:40     ` Patrick Steinhardt
2020-11-13 13:11 ` [PATCH 0/2] " Ævar Arnfjörð Bjarmason

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=X7NvrmisOs4g036W@ncase \ \ \ \ \ \
    --subject='Re: [PATCH 2/2] config: allow specifying config entries via envvar pairs' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).