Re: [PATCH 0/2] config: allow specifying config entries via envvar pairs

On Fri, Nov 13 2020, Patrick Steinhardt wrote:

this patch series adds a way to specify config entries via separate
envvars `GIT_CONFIG_KEY_$n` and `GIT_CONFIG_VALUE_$n`. There's two main
motivations:

    1. `GIT_CONFIG_PARAMETERS` is undocumented and requires parsing of
       the key-value pairs. This requires the user to properly escape
       all potentially harmful characters, which may be hard if the
       value is controlled by a third party.

    2. `git -c key=val` is not really suited to contain sensitive
       information, as command line arguments trivially show up in e.g.
       ps(1).

FWIW we had an off-list discussion about this where the desire was to
have the equivalent of a transitory password in a config file without
the bad pattern of putting it in an on-disk config file. The advertised
solution we have now is core.askpass, but a user might for some reason
not want the hassle of an external program.

I noted that you can do that with some clever hacks that aren't
explicitly documented:

1) Use the insteadOf config to on-the-fly rewrite a password-less https
   URL to have a user/password:

    git -c url.https://user:password@.insteadOf=https:// push

   But that has the downside of showing the password in "ps" as Patrick
   notes. That's OS dependant, but is the default on e.g. Linux, as
   opposed to envars. See "hidepid" in the "procfs" manpage.

2) Doing the same via an env var, but via GIT_CONFIG_PARAMETERS:

    GIT_CONFIG_PARAMETERS="'url.https://user:password@.insteadOf=https://'" git push

3) This doesn't work, but I wish it did. First put:

    [include]
    path = /dev/fd/321

   In your .git/config. Then:

    (echo "[url \"https://user:password\"]" && echo "insteadOf = https://") | { git remote get-url origin; } 321<&0

   The reason it doesn't work is because the "git remote" config
   machinery, unlike the general machinery, explicitly doesn't handle
   includes. I didn't poke at that for long, but I expect that's just an
   omission. It wants to not read remote.origin.url from ~/.gitconfig or
   whatever, but I don't see why we wouldn't follow includes in
   .git/config.