| Message ID | pull.1396.git.1666845947898.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Mention that password could be a personal access token. | expand |
"M Hickford via GitGitGadget" <gitgitgadget@gmail.com> writes: > `password`:: > > - The credential's password, if we are asking it to be stored. > + The credential's password, if we are asking it to be stored. If the > + host is a software forge, this could also be a personal access > + token or OAuth access token. Is this limited to software forge hosts? Also, I wonder if the specific "it can be access token and not password" is something worth adding. If there were a service styled after the good-old "anonymous ftp", it would expect the constant string 'anonymous' as the "username", and would expect to see your identity (e.g. 'mirth.hickford@gmail.com') as the "password". The point is that it does not matter what it is called on the end-user's side, be it a password or access token or whatever. It is what the other end that provides the service wants to see after you claimed who you are by providing "username", usually (but not necessarily) in order to prove your claim. So, I dunno.
On Thu, Oct 27, 2022 at 10:40:13AM -0700, Junio C Hamano wrote: > "M Hickford via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > `password`:: > > > > - The credential's password, if we are asking it to be stored. > > + The credential's password, if we are asking it to be stored. If the > > + host is a software forge, this could also be a personal access > > + token or OAuth access token. > > Is this limited to software forge hosts? > > Also, I wonder if the specific "it can be access token and not > password" is something worth adding. If there were a service styled > after the good-old "anonymous ftp", it would expect the constant > string 'anonymous' as the "username", and would expect to see your > identity (e.g. 'mirth.hickford@gmail.com') as the "password". The > point is that it does not matter what it is called on the end-user's > side, be it a password or access token or whatever. It is what the > other end that provides the service wants to see after you claimed > who you are by providing "username", usually (but not necessarily) > in order to prove your claim. > > So, I dunno. FWIW, I had the same reaction. From the client perspective for https, this is going over basic-auth, and it might be nice to just say so. But of course the whole credential system is abstract, so it gets awkward. We could probably say something like: The credential's password, if we are asking it to be stored. Note that this may not strictly be a traditional password, but rather any secret string which is used for authentication. For instance, Git's HTTP protocol will generally pass this using an Authorization header; depending on what the server is expecting this may be a password typed by the user, a personal access token, or some other opaque value. Maybe that is getting too into the weeds. OTOH, anybody reading this far into git-credential(1) is probably pretty technical. There may be a better way of wording it, too. Another way of thinking about it that it's basically any secret that is a single string, and not part of a challenge/response protocol. I couldn't find a way to word that which didn't end up more confusing, though. ;) -Peff
Jeff King <peff@peff.net> writes: > FWIW, I had the same reaction. From the client perspective for https, > this is going over basic-auth, and it might be nice to just say so. But > of course the whole credential system is abstract, so it gets awkward. > We could probably say something like: > > The credential's password, if we are asking it to be stored. Note that > this may not strictly be a traditional password, but rather any secret > string which is used for authentication. For instance, Git's HTTP > protocol will generally pass this using an Authorization header; > depending on what the server is expecting this may be a password typed > by the user, a personal access token, or some other opaque value. Thanks. I have no problem with this replacement text. > Maybe that is getting too into the weeds. OTOH, anybody reading this far > into git-credential(1) is probably pretty technical. True, too.
On Thu, 27 Oct 2022 at 18:40, Junio C Hamano <gitster@pobox.com> wrote: > Also, I wonder if the specific "it can be access token and not > password" is something worth adding. Personal access tokens are ubiquitous nowadays, maybe even more common than passwords since GitHub disabled passwords last year. I wanted to acknowledge this in the docs, even if Git's own behaviour hasn't changed. Maybe the introduction to https://git-scm.com/docs/gitcredentials would be a better place to do that? Git will sometimes need credentials from the user in order to perform operations; for example, it may need to ask for a username and password in order to access a remote repository over HTTP. **The server may accept or expect a personal access token instead of a password.** [1] https://github.blog/changelog/2021-08-12-git-password-authentication-is-shutting-down/
On Tue, Nov 01 2022, M Hickford wrote: > On Thu, 27 Oct 2022 at 18:40, Junio C Hamano <gitster@pobox.com> wrote: > >> Also, I wonder if the specific "it can be access token and not >> password" is something worth adding. > > Personal access tokens are ubiquitous nowadays, maybe even more common > than passwords since GitHub disabled passwords last year. I wanted > to acknowledge this in the docs, even if Git's own behaviour hasn't > changed. Maybe the introduction to > https://git-scm.com/docs/gitcredentials would be a better place to do > that? > > Git will sometimes need credentials from the user in order to > perform operations; for example, it may need to ask for a username and > password in order to access a remote repository over HTTP. **The > server may accept or expect a personal access token instead of a > password.** > > [1] https://github.blog/changelog/2021-08-12-git-password-authentication-is-shutting-down/ A "personal access token" is just a password by another name. When you enter such a token into your .git/config (or provide it via an auth helper) we'll sent it over via HTTP Basic Auth, "which transmits credentials as user-id/ password pairs, encoded using Base64"[2]. Even the blog post you linked to makes the distinction, by talking about "account passwords". I.e. what's really going on here is that providers have been moving to using N passwords instead of 1. Now, I'm not just trying to be pedantic. I do think there's probably a doc improvement to be made here. If popular providers are calling this a "[personal] access token" perhaps we should mention it in passing. But saying "this could also be" is the point at which this could create its own confusion. This *is* a password. E.g. if you get such a "token" and want to try it out with the "curl" utility (whose library we use for http) it'll be e.g.: curl --user <user>:<password> <url> Not: curl --user <user> --personal-access-token <token> <url> Or whatever. I.e. the entire rest of the stack calls this a "password", and that stack's a lot more likely to be what stays around in the long term, rather than what amounts to a marketing term for a password. 1. https://www.rfc-editor.org/rfc/rfc7617
On Tue, 1 Nov 2022 at 08:09, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > > what's really going on here is that providers > have been moving to using N passwords instead of 1. I like that way of thinking about it.
diff --git a/Documentation/git-credential.txt b/Documentation/git-credential.txt index f18673017f5..f3bf0bef54b 100644 --- a/Documentation/git-credential.txt +++ b/Documentation/git-credential.txt @@ -142,7 +142,9 @@ Git understands the following attributes: `password`:: - The credential's password, if we are asking it to be stored. + The credential's password, if we are asking it to be stored. If the + host is a software forge, this could also be a personal access + token or OAuth access token. `url`::