RE: [PATCH] docs: discuss caching personal access tokens

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Jan 10, 2025, 19:11 UTC
Message-ID: <017f01db6393$7e3fe2e0$7abfa8a0$@nexbridge.com>
In-Reply-To: <xmqqwmf27cvv.fsf@gitster.g>

On January 10, 2025 1:17 PM, Junio C Hamano wrote:

Show 27 quoted lines

>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

Show 7 quoted lines

>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.