From: Derrick Stolee <derrickstolee@github.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, gitster@pobox.com, peff@peff.net,
me@ttaylorr.com, christian.couder@gmail.com,
johannes.schindelin@gmx.de, jrnieder@gmail.com,
"brian m. carlson" <sandals@crustytoothpaste.net>,
Robert Coup <robert.coup@koordinates.com>
Subject: Re: [PATCH] urlmatch: create fetch.credentialsInUrl config
Date: Wed, 25 May 2022 10:03:43 -0400 [thread overview]
Message-ID: <b9eff859-ee1a-6cfd-7d83-e24284c14eec@github.com> (raw)
In-Reply-To: <220524.86ilpuvcqh.gmgdl@evledraar.gmail.com>
On 5/24/2022 5:01 PM, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, May 24 2022, Derrick Stolee wrote:
>
>> On 5/24/2022 4:18 AM, Ævar Arnfjörð Bjarmason wrote:
>>>
>>> On Mon, May 23 2022, Derrick Stolee via GitGitGadget wrote:
>>>
>>>> +fetch.credentialsInUrl::
>>>> + A URL can contain plaintext credentials in the form
>>>> + `protocol://<user>:<password>@domain/path`. Using such URLs is not
>>>> + recommended as it exposes the password in multiple ways. The
>>>> + `fetch.credentialsInUrl` option provides instruction for how Git
>>>> + should react to seeing such a URL, with these values:
>>>
>>> Re the previous discussion about this (in the v1 patch /
>>> https://lore.kernel.org/git/pull.945.git.1619807844627.gitgitgadget@gmail.com/):
>>> In what ways?
>>>
>>> That's rhetorical, the point being: Let's adjust this documentation to
>>> discuss exactly why this is thought to be bad, what we're mitigating for
>>> the user etc., are there situations where running git like this is
>>> perfectly fine & not thought to be an issue? E.g. no password manager
>>> and you trust your FS permission? Let's cover those cases too.
>>
>> This documentation is not the proper place to tell the user "do this
>> and you can trust your plaintext creds in the filesystem" because that
>> is asking for problems. I'd rather leave a vague warning and let users
>> go against the recommended behavior only after they have done sufficient
>> work to be confident in taking on that risk.
>
> I don't mean that we need to cover the full divergent views on different
> approaches to local password management, but not leave the user hanging
> with the rather scary "exposes the password in multiple ways".
>
> I.e. if I read that for any software whose implementation I wasn't very
> familiar with I'd be very afraid, and in git's case for no reason.
>
> Does in mean that git has some scary git-specific feature that would
> expose it. perhaps there's a local log that's unsecured where attempted
> URLs are logged, or perhaps we send the raw requested URL to the server
> so it can suggest alternatives for us. We do neither, but even a
> generally knowledgeable user won't know that about git in particular.
>
> Whereas what I think you actually mean and are targeting here is better
> explained by:
>
> Git is careful to avoid exposing passwords in URLs on its own,
> e.g. they won't be logged in trace2 logs. This setting is intended
> for those who'd like to discourage (warn) or enforce (die) the use
> of the password helper infrastructure over hardcoded passwords.
>
> All of which I *think* is correct, but maybe I've missed something you
> know about, as that "in multiple ways" is doing a lot of work.
>
> I also wonder if this wouldn't be even more useful if we took some
> lessons from ssh's book. I.e. per "git config -l --show-origin" we know
> the original of all config. We could be even more useful (and more
> aggressive about warning about) cases where we have passwords in config
> files that we detect don't have restrictive permissions, as OpenSSH does
> with your private key.
>
> Ditto perhaps when the origin is "command line", as we do nothing to
> hide that from the process list on shared systems (and that would be
> racy whatever we did).
I tried to be careful about how "it" (being "Using such URLs") can
expose the password includes things that are not under Git's
responsibility (such as command-line histories and other system-level
logs) but I can add a bit about how Git stores the plaintext password
in the repository's config.
>>>> + char *value = NULL;
>>>
>>> This init to NULL should be removedd, as we....
>>>
>>>> + const char *at_ptr;
>>>> + const char *colon_ptr;
>>>> + struct strbuf anonymized = STRBUF_INIT;
>>>
>>> nit: Just call this "sb"? The's at least one line below over 79
>>> characters that's within the bounds with a shorter variable name, and in
>>> this case it's obvious what we're doing here...
>>
>> I will not change this name to be less descriptive.
>
> Sure, just a suggestion. The other way is to just re-wrap that one
> line... :)
>
> In the end I don't care, "just a nit", but just as one datapoint from
> reading this code: I find this varibale name in particular to be the
> polar opposite of descriptive, we're explicitly not anonymizing the URL
> in this function, since we're not stripping the username part.
>
> Wouldn't descriptive be something more like uri_redacted_password or
> uri_no_password in this case?
How about "redacted"?
> Just for the implementation: It's slightly more wasteful, but in this
> case we don't care about performance, so perhaps a strbuf_splice()
> variant is easier here? I.e. add the full URL, find : and @, then
> strbuf_splice() it. It gets rid of much of the pointer juggling here &
> adding things incrementally.
TIL. strbuf_splice() will work perfectly. Thanks.
-Stolee
next prev parent reply other threads:[~2022-05-25 14:07 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-23 18:04 [PATCH] urlmatch: create fetch.credentialsInUrl config Derrick Stolee via GitGitGadget
2022-05-23 19:06 ` Junio C Hamano
2022-05-23 20:31 ` Derrick Stolee
2022-05-23 21:14 ` Junio C Hamano
2022-05-24 11:46 ` Johannes Schindelin
2022-05-24 20:14 ` Derrick Stolee
2022-05-23 20:37 ` Junio C Hamano
2022-05-24 11:51 ` Johannes Schindelin
2022-05-24 8:18 ` Ævar Arnfjörð Bjarmason
2022-05-24 13:50 ` Derrick Stolee
2022-05-24 21:01 ` Ævar Arnfjörð Bjarmason
2022-05-25 14:03 ` Derrick Stolee [this message]
2022-05-24 11:42 ` Johannes Schindelin
2022-05-24 20:16 ` Derrick Stolee
2022-05-27 13:27 ` [PATCH v2] " Derrick Stolee via GitGitGadget
2022-05-27 14:22 ` Ævar Arnfjörð Bjarmason
2022-05-27 14:43 ` Derrick Stolee
2022-05-27 18:09 ` Junio C Hamano
2022-05-27 18:40 ` Junio C Hamano
2022-05-30 0:16 ` Junio C Hamano
2022-05-31 13:32 ` Derrick Stolee
2022-06-01 1:16 ` [PATCH v3 0/2] fetch: " Derrick Stolee via GitGitGadget
2022-06-01 1:16 ` [PATCH v3 1/2] remote: " Derrick Stolee via GitGitGadget
2022-06-01 19:19 ` Ævar Arnfjörð Bjarmason
2022-06-02 13:38 ` Derrick Stolee
2022-06-01 1:16 ` [PATCH v3 2/2] usage: add warn_once() helper for repeated warnings Derrick Stolee via GitGitGadget
2022-06-01 12:29 ` Ævar Arnfjörð Bjarmason
2022-06-01 18:42 ` Derrick Stolee
2022-06-01 19:33 ` Ævar Arnfjörð Bjarmason
2022-06-02 13:43 ` Derrick Stolee
2022-06-01 20:21 ` Junio C Hamano
2022-06-02 14:24 ` Derrick Stolee
2022-06-02 17:53 ` Junio C Hamano
2022-06-01 20:40 ` Junio C Hamano
2022-06-02 17:20 ` [PATCH v4] remote: create fetch.credentialsInUrl config Derrick Stolee via GitGitGadget
2022-06-02 21:20 ` Junio C Hamano
2022-06-03 12:54 ` Derrick Stolee
2022-06-06 15:37 ` Junio C Hamano
2022-06-06 14:36 ` [PATCH v5] " Derrick Stolee via GitGitGadget
2022-06-06 16:34 ` Junio C Hamano
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=b9eff859-ee1a-6cfd-7d83-e24284c14eec@github.com \
--to=derrickstolee@github.com \
--cc=avarab@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
--cc=jrnieder@gmail.com \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
--cc=robert.coup@koordinates.com \
--cc=sandals@crustytoothpaste.net \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).