Subject: Re: transfer.credentialsInUrl should warn about personal access tokens in user field #leftoverbits

From: "brian m. carlson" <[email-masked]>
Date: Sat, 11 Jan 2025 00:08:05 +0000

On 2025-01-10 at 22:51:01, Junio C Hamano wrote:
> Yes, I do strongly object us to keep a hardcoded list that can go
> stale (or be stale from the beginning).
> 
> What I was wondering is that because we are in control of the Git
> end of the credential subsystem (even if the user may be using a
> third-party credential helper), we
> 
>  - can notice that the URL has embedded single thing (which could be
>    username, but which could be a token);
> 
>  - can also notice that we asked the credential-helper, or
>    keyboard-interactive, and obtained a password (or not).
> 
> When the former is true and the latter is false, it is an indication
> that for that site with the username-or-token, there wasn't anything
> necessary to authenticate and the access was authorized.  Which is
> what the original poster wants us to warn against.

No, I don't think that will work in the general case.  Here's why.  If I
do `git push https://[email-masked]/git/bmc/xyzzy.git`,
that uses Kerberos (Negotiate).  There's a username there to make
libcurl enable auth, but it's never used and a credential helper is
never invoked, so case 1 is true and case 2 is false.

Now, we _could_ do that only for Basic auth, which would catch the
GitHub case.  However, it's _also_ possible to use TLS client
certificate auth (and I think Bitbucket does support that) and use the
username only for choosing the account (because, say, your work account
uses a client certificate and your personal account uses something
else).  There might be Basic auth sent (say, if you'd set
`http.proactiveAuth`), but the server would ignore it since you were
already authenticated via the TLS cert.  That would also make case 1 be
true and case 2 be false.

Perhaps that latter case is not worth worrying about, but it is a
possibility and I'm sure some people will hit it.  Maybe with a config
option for the advice that's okay, though.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA