docs: discuss caching personal access tokens #1851
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
There are issues in commit e2298b6: |
hickford
force-pushed
the
cache-pat-docs
branch
from
e2298b6 to
1980f6a
Compare
|
/submit |
|
Submitted as [email protected] To fetch this version into To fetch this version to local tag |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): "M Hickford via GitGitGadget" <[email protected]> writes:
> From: M Hickford <[email protected]>
>
> Describe problems storing personal access tokens in git-credential-cache
> and suggest alternatives.
> +PERSONAL ACCESS TOKENS
> +----------------------
> +
> +Some remotes accept personal access tokens, which are randomly
> +generated and hard to memorise. They typically have a lifetime of weeks
> +or months.
> +
> +git-credential-cache is inherently unsuitable for persistent storage of
> +personal access tokens. The credential will be forgotten after the cache
> +timeout. Even if you configure a long timeout, credentials will be
> +forgotten if the daemon dies.
Very true.
> +To avoid frequently regenerating personal access tokens, configure a
> +credential helper with persistent storage.
Like libsecret and osxkeychain, you mean? I am wondering if we want
to be a bit more helpful by being explicit. I think there is a
section in a maual page that has a list of known and often-used
credential backends, so referring the readers to that section may be
helpful.
> Alternatively, configure an
> +OAuth credential helper to generate credentials automatically. See
> +linkgit:gitcredentials[7].
Indeed. |
|
On the Git mailing list, wrote (reply to this): On January 10, 2025 1:17 PM, Junio C Hamano wrote:
>Subject: Re: [PATCH] docs: discuss caching personal access tokens
>
>"M Hickford via GitGitGadget" <[email protected]> writes:
>
>> From: M Hickford <[email protected]>
>>
>> Describe problems storing personal access tokens in
>> git-credential-cache and suggest alternatives.
>
>> +PERSONAL ACCESS TOKENS
>> +----------------------
>> +
>> +Some remotes accept personal access tokens, which are randomly
>> +generated and hard to memorise. They typically have a lifetime of
>> +weeks or months.
>> +
>> +git-credential-cache is inherently unsuitable for persistent storage
>> +of personal access tokens. The credential will be forgotten after the
>> +cache timeout. Even if you configure a long timeout, credentials will
>> +be forgotten if the daemon dies.
>
>Very true.
>
>> +To avoid frequently regenerating personal access tokens, configure a
>> +credential helper with persistent storage.
>
>Like libsecret and osxkeychain, you mean? I am wondering if we want to be
a bit
>more helpful by being explicit. I think there is a section in a maual page
that has a
>list of known and often-used credential backends, so referring the readers
to that
>section may be helpful.
>
>> Alternatively, configure an
>> +OAuth credential helper to generate credentials automatically. See
>> +linkgit:gitcredentials[7].
>
>Indeed.
My solution for this is to write a custom credential manager that is PAT
aware. The one I built
does not support OAuth or OAuth2. This is non-trivial when dealing with a
CLI. Integrating
with something like MS Authenticator might be a reasonable option for some.
|
|
User |
hickford
force-pushed
the
cache-pat-docs
branch
from
1980f6a to
1e33e7c
Compare
|
There are issues in commit 286bbfc: |
|
On the Git mailing list, M Hickford wrote (reply to this): On Fri, 10 Jan 2025 at 18:16, Junio C Hamano <[email protected]> wrote:
>
> "M Hickford via GitGitGadget" <[email protected]> writes:
>
> > From: M Hickford <[email protected]>
> >
> > Describe problems storing personal access tokens in git-credential-cache
> > and suggest alternatives.
>
> > +PERSONAL ACCESS TOKENS
> > +----------------------
> > +
> > +Some remotes accept personal access tokens, which are randomly
> > +generated and hard to memorise. They typically have a lifetime of weeks
> > +or months.
> > +
> > +git-credential-cache is inherently unsuitable for persistent storage of
> > +personal access tokens. The credential will be forgotten after the cache
> > +timeout. Even if you configure a long timeout, credentials will be
> > +forgotten if the daemon dies.
>
> Very true.
>
> > +To avoid frequently regenerating personal access tokens, configure a
> > +credential helper with persistent storage.
>
> Like libsecret and osxkeychain, you mean? I am wondering if we want
> to be a bit more helpful by being explicit. I think there is a
> section in a maual page that has a list of known and often-used
> credential backends, so referring the readers to that section may be
> helpful.
I agree, explicit is more helpful. I shall expand that
gitcredentials.txt section in patch v2.
>
> > Alternatively, configure an
> > +OAuth credential helper to generate credentials automatically. See
> > +linkgit:gitcredentials[7].
>
> Indeed. |
git-credential-store saves credentials unencrypted on disk. It is the least secure choice of credential helper. Nevertheless, it appears several times more popular than any other credential helper [1]. Inform users about more secure alternatives. [1] https://stackoverflow.com/questions/35942754/how-can-i-save-username-and-password-in-git Signed-off-by: M Hickford <[email protected]>
Describe problems storing personal access tokens in git-credential-cache and suggest alternatives. Research suggests that many users are confused about this: > the point of passwords is that (ideally) you memorise them [so] > they're never stored anywhere in plain text. Yet GitHub's personal > access token system seems to basically force you to store the token in > plain text? https://stackoverflow.com/questions/46645843/where-to-store-my-git-personal-access-token#comment89963004_46645843 Signed-off-by: M Hickford <[email protected]>
hickford
force-pushed
the
cache-pat-docs
branch
from
1e33e7c to
ac8c5e1
Compare
|
/submit |
|
Submitted as [email protected] To fetch this version into To fetch this version to local tag |
|
This patch series was integrated into seen via git@89052f4. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
CC: [email protected]
CC: [email protected]
CC: [email protected]
CC: [email protected]
CC: [email protected]
cc: [email protected]
Patch v2 adds a list of popular credential helpers.