From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: M Hickford <mirth.hickford@gmail.com>,
git@vger.kernel.org, derrickstolee@github.com,
stolee@gmail.com
Subject: Re: transfer.credentialsInUrl should warn about personal access tokens in user field #leftoverbits
Date: Fri, 10 Jan 2025 14:51:01 -0800 [thread overview]
Message-ID: <xmqqa5by5lm2.fsf@gitster.g> (raw)
In-Reply-To: <Z4GZ0oiZCC2Wl3bN@tapette.crustytoothpaste.net> (brian m. carlson's message of "Fri, 10 Jan 2025 22:06:10 +0000")
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> I don't think in general we can know whether a credential is just a
> plain username or a token without trying to guess based on the content.
> For instance, before `http.emptyAuth`, it was common if one was using
> Kerberos to put one's username in the URL because that triggered libcurl
> to do authentication, whereas it would not if no credentials were
> specified. I still have that configured, and I bet a lot of others do
> as well.
>
> It's also common for people with both work and personal accounts on a
> site to put the username in the URL so that the correct credentials are
> looked up in the credential helper. And all of that is fine and secure
> since there are no actual secrets in the username in those cases.
>
> So there are lots of legitimate reasons to place only a username there,
> and we'd only be able to know if it's actually a token by hard-coding
> patterns. I would recommend that we not do that, since I can't
> guarantee that the list of patterns won't expand in the future (it
> already has before), and there are still some older hex-only patterns
> which may be in use and which are much less obvious.
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.
And if we can do so, we do not need any list of patterns, right?
next prev parent reply other threads:[~2025-01-10 22:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-10 21:05 transfer.credentialsInUrl should warn about personal access tokens in user field #leftoverbits M Hickford
2025-01-10 21:32 ` Junio C Hamano
2025-01-10 22:06 ` brian m. carlson
2025-01-10 22:51 ` Junio C Hamano [this message]
2025-01-11 0:08 ` brian m. carlson
2025-01-11 0:45 ` Junio C Hamano
2025-01-11 1:01 ` rsbecker
2025-01-18 20:33 ` M Hickford
2025-01-10 22:10 ` rsbecker
2025-01-10 23:36 ` Randall Becker
2025-01-10 23:44 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqa5by5lm2.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=mirth.hickford@gmail.com \
--cc=sandals@crustytoothpaste.net \
--cc=stolee@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).