Re: [PATCH] urlmatch: create fetch.credentialsInUrl config
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- May 24, 2022, 11:46 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2205241343390.352@tvgsbejvaqbjf.bet>
- In-Reply-To
- <7495dac8-0241-ad56-59e3-100673c88c52@github.com>
Hi Stolee,
On Mon, 23 May 2022, Derrick Stolee wrote:
Show 21 quoted lines
> 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.
Show 7 quoted lines
> > 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