git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Jan 11, 2025, 00:08 UTC
Message-ID
<Z4G2Ze8S5PKfKjmI@tapette.crustytoothpaste.net>
In-Reply-To
<xmqqa5by5lm2.fsf@gitster.g>
On 2025-01-10 at 22:51:01, Junio C Hamano wrote:
Show 17 quoted lines
> 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@git.crustytoothpaste.net/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
Previous: Junio C HamanoNext: Junio C Hamano
Message 5 of 11 in “transfer.credentialsInUrl should warn about personal access tokens in user field #leftoverbits”
  1. M HickfordJan 10, 2025
  2. Junio C HamanoJan 10, 2025
  3. brian m. carlsonJan 10, 2025
  4. Junio C HamanoJan 10, 2025
  5. brian m. carlsonJan 11, 2025
  6. Junio C HamanoJan 11, 2025
  7. rsbecker@nexbridge.comJan 11, 2025
  8. M HickfordJan 18, 2025
  9. rsbecker@nexbridge.comJan 10, 2025
  10. Randall BeckerJan 10, 2025
  11. Junio C HamanoJan 10, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.