git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>
Cc: 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>,
	Derrick Stolee <derrickstolee@github.com>
Subject: Re: [PATCH] urlmatch: create fetch.credentialsInUrl config
Date: Tue, 24 May 2022 10:18:13 +0200	[thread overview]
Message-ID: <220524.8635gzxr9h.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <pull.1237.git.1653329044940.gitgitgadget@gmail.com>


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.

> ++
> +* `ignore` (default): Git will proceed with its activity without warning.
> +* `warn`: Git will write a warning message to `stderr` when parsing a URL
> +  with a plaintext credential.
> +* `die`: Git will write a failure message to `stderr` when parsing a URL
> +  with a plaintext credential.

You're implementing this with strcasecmp, so we also support DIE, DiE
etc. Let's not do that and use strcmp() instead.

> diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
> index 4a61f2c901e..34be520b783 100755
> --- a/t/t5601-clone.sh
> +++ b/t/t5601-clone.sh
> @@ -71,6 +71,13 @@ test_expect_success 'clone respects GIT_WORK_TREE' '
>  
>  '
>  
> +test_expect_success 'clone warns or fails when using username:password' '
> +	test_must_fail git -c fetch.credentialsInUrl=warn clone https://username:password@localhost attempt1 2>err &&
> +	grep "warning: URL '\''https://username:\*\*\*\*\*\*\*\*@localhost/'\'' uses plaintext credentials" err &&
> +	test_must_fail git -c fetch.credentialsInUrl=die clone https://username:password@localhost attempt2 2>err &&
> +	grep "fatal: URL '\''https://username:\*\*\*\*\*\*\*\*@localhost/'\'' uses plaintext credentials" err
> +'
> +
>  test_expect_success 'clone from hooks' '
>  
>  	test_create_repo r0 &&
> diff --git a/urlmatch.c b/urlmatch.c
> index b615adc923a..6b91fb648a7 100644
> --- a/urlmatch.c
> +++ b/urlmatch.c
> @@ -1,5 +1,6 @@
>  #include "cache.h"
>  #include "urlmatch.h"
> +#include "config.h"
>  
>  #define URL_ALPHA "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
>  #define URL_DIGIT "0123456789"
> @@ -106,6 +107,46 @@ static int match_host(const struct url_info *url_info,
>  	return (!url_len && !pat_len);
>  }
>  
> +static void detected_credentials_in_url(const char *url, size_t scheme_len)
> +{

Just generally: This is only 

> +	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...
> +
> +	/* "ignore" is the default behavior. */
> +	if (git_config_get_string("fetch.credentialsinurl", &value) ||

...initialize it here, and if we didn't the compiler would have a chance
to spot that if we were getting it wrong.

> +	    !strcasecmp("ignore", value))
> +		goto cleanup;
> +
> +	at_ptr = strchr(url, '@');
> +	colon_ptr = strchr(url + scheme_len + 3, ':');
> +
> +	if (!colon_ptr)
> +		BUG("failed to find colon in url '%s' with scheme_len %"PRIuMAX,
> +		    url, (uintmax_t) scheme_len);
> +
> +	/* Include everything including the colon. */
> +	colon_ptr++;
> +	strbuf_add(&anonymized, url, colon_ptr - url);
> +
> +	while (colon_ptr < at_ptr) {
> +		strbuf_addch(&anonymized, '*');
> +		colon_ptr++;
> +	}

Could we share code with 88e9b1e3fcb (fetch-pack: redact packfile urls
in traces, 2021-11-10), or for consistency note this as <redacted>
instead of stripping it out, as we do for that related URL-part
redaction?

> +	strbuf_addstr(&anonymized, at_ptr);

Maybe not worth it, but I wondered if we couldn't just use curl for
this, turns out it has an API for it:
https://curl.se/libcurl/c/libcurl-url.html

But it's too new for us to rely on unconditionally, but we could add
that to git-curl-compat.h and ifdef it, then we'll eventually drop this
custom code for ryling on the well-tested library.

I think doing that would be worth it, to show future authors that curl
can do this, so maybe we can start relying on that eventually...

> +	if (!strcasecmp("warn", value))
> +		warning(_("URL '%s' uses plaintext credentials"), anonymized.buf);
> +	if (!strcasecmp("die", value))
> +		die(_("URL '%s' uses plaintext credentials"), anonymized.buf);
> +
> +cleanup:
> +	free(value);

I think you can also just use git_config_get_string_tmp() here and avoid
the alloc/free. That's safe as long as you're not calling other config
API in-between, which you're not.

  parent reply	other threads:[~2022-05-24  8:35 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 [this message]
2022-05-24 13:50   ` Derrick Stolee
2022-05-24 21:01     ` Ævar Arnfjörð Bjarmason
2022-05-25 14:03       ` Derrick Stolee
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=220524.8635gzxr9h.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=derrickstolee@github.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).