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://bmc@xxxxxxxxxxxxxxxxxxxxxxxx/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
Attachment:
signature.asc
Description: PGP signature
