Re: [PATCH] docs: clarify that credential discards unrecognised attributes

From: M Hickford <mirth.hickford@gmail.com>
Date: Nov 12, 2022, 19:08 UTC
Message-ID: <CAGJzqsnd3UbCuj6xfsAgVEFz5OaDBhnCTNeAvOVPK9NWBDnDRA@mail.gmail.com>
In-Reply-To: <Y2/OIrSz+xrqkd+C@coredump.intra.peff.net>

On Sat, 12 Nov 2022 at 16:47, Jeff King <peff@peff.net> wrote:

Show 16 quoted lines

> > > We did discuss patches a long time ago that would let Git carry
> > > arbitrary keys between helpers, even if Git itself didn't understand it.
> > > One of the intended uses was to let helpers talk to each other about
> > > TTLs. So if you had say:
> > >
> > >   [credential]
> > >   helper = generate-some-token
> > >   helper = cache
> > >
> > > where the first helper generates a token, and the second caches it, the
> > > first one could shove a "ttl" or "expiration" key into the protocol,
> > > which the cache could then learn to respect.
> >
>
> What you're doing works fine with the code as-is; you just can't carry
> extra data (like a ttl) between the two.

FWIW I have a draft patch that adds password_expiry_utc and oauth_refresh_token attributes to credential https://github.com/gitgitgadget/git/pull/1394 introducing expiry logic in the credential layer. I'll share a RFC sometime in future.

> I agree for GitHub's tokens that the times involved make auto-expiration
> not that important. The example back in that thread was something more
> time-limited (like minutes or hours). I don't know how often that kind
> of things is in the wild.

GitLab OAuth tokens expire after 2 hours (the refresh tokens are valid longer). This is a security improvement over long-lived tokens.