list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <>
To: Patrick Steinhardt <>
Subject: Re: [PATCH 0/2] config: allow specifying config entries via envvar pairs
Date: Fri, 13 Nov 2020 14:11:55 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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:

    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

      parent reply	other threads:[~2020-11-13 13:12 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13 12:16 [PATCH 0/2] config: allow specifying config entries via envvar pairs 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
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 ` Ævar Arnfjörð Bjarmason [this message]

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 \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public 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).