Re: [PATCH] urlmatch: create fetch.credentialsInUrl config

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Stolee,

On Mon, 23 May 2022, Derrick Stolee wrote:

> On 5/23/2022 3:06 PM, Junio C Hamano wrote:
> > "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
> >
> >> +static void detected_credentials_in_url(const char *url, size_t scheme_len)
> >> +{
> >> +	char *value = NULL;
> >> +	const char *at_ptr;
> >> +	const char *colon_ptr;
> >> +	struct strbuf anonymized = STRBUF_INIT;
> >> +
> >> +	/* "ignore" is the default behavior. */
> >> +	if (git_config_get_string("fetch.credentialsinurl", &value) ||
> >> +	    !strcasecmp("ignore", value))
> >> +		goto cleanup;
> >> +
> >> +	at_ptr = strchr(url, '@');
> >> +	colon_ptr = strchr(url + scheme_len + 3, ':');
> >
> > We expect that at_ptr would come after colon_ptr (i.e. in
> > "scheme://<u>:<p>@host", no @ exists in <u> or <p> part) and the
> > while() loop below assumes that for redacting.

Careful here. https://me@there.com:9999/ _is_ a valid URL, too.

> > Are we better off if we assert it here, or has the calling parser
> > already rejected such cases?
>
> This computation of at_ptr matches the one in url_normalize_1(),
> so it at least agrees about where the "username[:password]" section
> could be. That does mean that the password cannot contain an "@"
> symbol (unless it is special-cased somehow?).

The password cannot contain a literal `@`, and neither can the user name.
They have to be URL-encoded, via `%40`.

Ciao,
Dscho