| Message ID | pull.1851.git.1736458019921.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | docs: discuss caching personal access tokens | expand |
"M Hickford via GitGitGadget" <gitgitgadget@gmail.com> writes: > From: M Hickford <mirth.hickford@gmail.com> > > 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 January 10, 2025 1:17 PM, Junio C Hamano wrote: >Subject: Re: [PATCH] docs: discuss caching personal access tokens > >"M Hickford via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> From: M Hickford <mirth.hickford@gmail.com> >> >> 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.
On Fri, 10 Jan 2025 at 18:16, Junio C Hamano <gitster@pobox.com> wrote: > > "M Hickford via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > From: M Hickford <mirth.hickford@gmail.com> > > > > 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.
diff --git a/Documentation/git-credential-cache.txt b/Documentation/git-credential-cache.txt index 487cc557a87..18e9933674a 100644 --- a/Documentation/git-credential-cache.txt +++ b/Documentation/git-credential-cache.txt @@ -78,6 +78,23 @@ variable (this example increases the cache time to 1 hour): $ git config credential.helper 'cache --timeout=3600' ------------------------------------------------------- +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. + +To avoid frequently regenerating personal access tokens, configure a +credential helper with persistent storage. Alternatively, configure an +OAuth credential helper to generate credentials automatically. See +linkgit:gitcredentials[7]. + GIT --- Part of the linkgit:git[1] suite