Mention that password could be a personal access token.
PATCH 1/1 Mention that password could be a personal access token.
From: M Hickford <[email protected]>
These days, the 'password' for a software forge might be personal access token or OAuth access token.
---
Mention that password could be a personal access token.
These days, the 'password' for a software forge might be personal access token or OAuth access token.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1396%2Fhickford%2Fmore-about-credentials-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1396/hickford/more-about-credentials-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1396
Documentation/git-credential.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Documentation/git-credential.txt +3 -1
@@ -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`::
base-commit: 1fc3c0ad407008c2f71dd9ae1241d8b75f8ef886
Signature · 1 line
gitgitgadget
Documentation/git-credential.txt Git understands the following attributes: · line 147
Quoted 6 lines · M Hickford via GitGitGadget
password::Documentation/git-credential.txt +3
-1- 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. '[email protected]') 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.
Quoted 22 lines · Junio C Hamano
Documentation/git-credential.txt Git understands the following attributes: · line 147
Quoted 6 lines · M Hickford via GitGitGadget
password::Documentation/git-credential.txt +3
-1- 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. '[email protected]') 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.
Quoted 1 line
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
Quoted 11 lines · Jeff King
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.
Quoted 2 lines
Maybe that is getting too into the weeds. OTOH, anybody reading this far into git-credential(1) is probably pretty technical.
True, too.
Quoted 2 lines · Junio C Hamano
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/
Quoted 12 lines · M Hickford
Quoted 2 lines · Junio C Hamano
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?
Quoted 7 lines
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.
Quoted 3 lines · Ævar Arnfjörð Bjarmason
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.
PATCH v2 1/1 Mention that password could be a personal access token.
In reply to M Hickford via GitGitGadgetFrom: M Hickford <[email protected]>
These days, the 'password' for a software forge might be personal access token or OAuth access token. These are popular, so worth clarifying that Git treats them just the same.
---
Mention that password could be a personal access token.
These days, the 'password' for a software forge might be personal access token or OAuth access token.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1396%2Fhickford%2Fmore-about-credentials-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1396/hickford/more-about-credentials-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/1396
Range-diff vs v1:
1: fef359f533a < -: ----------- Mention that password could be a personal access token. -: ----------- > 1: 0bb69988ad7 Mention that password could be a personal access token.
Documentation/gitcredentials.txt | 3 +++ 1 file changed, 3 insertions(+)
Documentation/gitcredentials.txt +3 -0
@@ -21,6 +21,9 @@ in order to access a remote repository over HTTP. This manual describes the mechanisms Git uses to request these credentials, as well as some features to avoid inputting these credentials repeatedly. +Some repositories accept multiple passwords, including personal access +tokens and OAuth access tokens. Git handles all of these the same. + REQUESTING CREDENTIALS ----------------------
base-commit: c03801e19cb8ab36e9c0d17ff3d5e0c3b0f24193
Signature · 1 line
gitgitgadget
Documentation/gitcredentials.txt in order to access a remote repository over HTTP. This manual describes · line 25
Quoted 13 lines · M Hickford via GitGitGadget
These days, the 'password' for a software forge might be personal access token or OAuth access token. These are popular, so worth clarifying that Git treats them just the same.
Signed-off-by M Hickford <[email protected]>---
Documentation/gitcredentials.txt +2
-0@@ -21,6 +21,9 @@ in order to access a remote repository over HTTP. This manual describes the mechanisms Git uses to request these credentials, as well as some features to avoid inputting these credentials repeatedly. +Some repositories accept multiple passwords, including personal access +tokens and OAuth access tokens. Git handles all of these the same.
I easily understood Ævar's point about these types of secrets all being different names for a password, but I find the above change rather confusing when it mentions "multiple passwords". That makes me think I may need to somehow configure multiple passwords for a site (even though I know that's not what you meant).
How about a different approach, calling it a "secret" first, and then defining "secret" as different names for "password". Perhaps something like this:
Git will sometimes need credentials from the user in order to perform operations; for example, it may need to ask for a username and secret in order to access a remote repository over HTTP. The secret may be a password, passcode, personal access token, OAuth access token, etc. This manual describes the mechanisms Git uses to request these credentials, as well as some features to avoid inputting these credentials repeatedly.
Quoted 3 lines · Eric Sunshine
How about a different approach, calling it a "secret" first, and then defining "secret" as different names for "password".
Or more directly, say "password" and parenthetically add that some hosting sites may call it with different names like "personal tokens"?
Quoted 6 lines · Junio C Hamano
Quoted 2 lines · Eric Sunshine
How about a different approach, calling it a "secret" first, and then defining "secret" as different names for "password".
Or more directly, say "password" and parenthetically add that some hosting sites may call it with different names like "personal tokens"?
I tried the parenthetical approach first but the sentence structure became too complex and more difficult to understand. Having a separate sentence helped simplify. That said, perhap something like this?
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. In place of a password, some sites may instead provide a passcode, personal access token, OAuth access token, etc. This manual...
Quoted 6 lines · Eric Sunshine
Quoted 5 lines · Junio C Hamano
Quoted 2 lines · Eric Sunshine
How about a different approach, calling it a "secret" first, and then defining "secret" as different names for "password".
Or more directly, say "password" and parenthetically add that some hosting sites may call it with different names like "personal tokens"?
Quoted 7 lines
I tried the parenthetical approach first but the sentence structure became too complex and more difficult to understand. Having a separate sentence helped simplify. That said, perhap something like this?
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. In
Perhaps s/password/secret 'password'/ here 9above0, and then talk about the names for that "secret" in the follow up sentence below.
Quoted 2 lines
place of a password, some sites may instead provide a passcode, personal access token, OAuth access token, etc. This manual...
--
Philip
Quoted 3 lines · Junio C Hamano
Or more directly, say "password" and parenthetically add that some hosting sites may call it with different names like "personal tokens"?
Right, Git asks for a "password", but the user might enter a personal access token instead.
PATCH v3 1/1 Mention that password could be a personal access token.
In reply to M Hickford via GitGitGadgetFrom: M Hickford <[email protected]>
Git asks for a "password", but the user might use a personal access token or OAuth access token instead.
Example:
Password for 'https://[email protected]':
---
Mention that password could be a personal access token.
These days, the 'password' for a software forge might be personal access token or OAuth access token.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1396%2Fhickford%2Fmore-about-credentials-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1396/hickford/more-about-credentials-v3
Pull-Request: https://github.com/gitgitgadget/git/pull/1396
Range-diff vs v2:
1: 0bb69988ad7 ! 1: 7be4a631aca Mention that password could be a personal access token.
@@ Metadata
## Commit message ##
Mention that password could be a personal access token.
- These days, the 'password' for a software forge might be personal access
- token or OAuth access token. These are popular, so worth clarifying that
- Git treats them just the same.
+ Git asks for a "password", but the user might use a
+ personal access token or OAuth access token instead.
+
+ Example:
+
+ Password for 'https://[email protected]':
## Documentation/gitcredentials.txt ##
-@@ Documentation/gitcredentials.txt: in order to access a remote repository over HTTP. This manual describes
- the mechanisms Git uses to request these credentials, as well as some
- features to avoid inputting these credentials repeatedly.
+@@ Documentation/gitcredentials.txt: DESCRIPTION
+
+ 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. This manual describes
+-the mechanisms Git uses to request these credentials, as well as some
+-features to avoid inputting these credentials repeatedly.
++in order to access a remote repository over HTTP. Some remotes accept
++a personal access token or OAuth access token as a password. This
++manual describes the mechanisms Git uses to request these credentials,
++as well as some features to avoid inputting these credentials repeatedly.
-+Some repositories accept multiple passwords, including personal access -+tokens and OAuth access tokens. Git handles all of these the same. -+
REQUESTING CREDENTIALS
----------------------
-
Documentation/gitcredentials.txt | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
Documentation/gitcredentials.txt +4 -3
@@ -17,9 +17,10 @@ DESCRIPTION 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. This manual describes -the mechanisms Git uses to request these credentials, as well as some -features to avoid inputting these credentials repeatedly. +in order to access a remote repository over HTTP. Some remotes accept +a personal access token or OAuth access token as a password. This +manual describes the mechanisms Git uses to request these credentials, +as well as some features to avoid inputting these credentials repeatedly. REQUESTING CREDENTIALS ----------------------
base-commit: 3b08839926fcc7cc48cf4c759737c1a71af430c1
Signature · 1 line
gitgitgadget
Quoted 4 lines · M Hickford via GitGitGadget
From: M Hickford <[email protected]>
Git asks for a "password", but the user might use a personal access token or OAuth access token instead.
Looks good to me. The only minor issue I noticed was that the commit message should have been prefixed with an area but wasn't.
I changed it to the following when queueing:
Documentation/gitcredentials.txt: mention password alternatives
Thank you for your work. Let's start merging this one down.
Thanks,
Taylor