"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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?
