From: Jeff King <email@example.com>
To: M Hickford <firstname.lastname@example.org>
Cc: Taylor Blau <email@example.com>,
M Hickford via GitGitGadget <firstname.lastname@example.org>,
Subject: Re: [PATCH] docs: clarify that credential discards unrecognised attributes
Date: Mon, 14 Nov 2022 17:40:20 -0500 [thread overview]
Message-ID: <Y3LD1Ilq8kLPlJMO@coredump.intra.peff.net> (raw)
On Sat, Nov 12, 2022 at 07:08:42PM +0000, M Hickford wrote:
> On Sat, 12 Nov 2022 at 16:47, Jeff King <email@example.com> wrote:
> > > > 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'm not _totally_ opposed to introducing these as something Git
understands, but I think it makes more sense to just teach Git to relay
unknown entries between helpers.
The oauth thing is going to be very helper specific, and not something I
think Git would ever do anything with itself.
In theory Git might care about expiration, but in practice I think it
doesn't. It's very unlikely for a token to expire in the course of Git
using it. It's only much later, when we ask for it back, that a helper
will notice it's expired. Git could save the helper some work by
noticing this on read, but since the helper has to learn to store and
report the expiration in the first place, not much is gained.
And in the case of something like credential-cache, we want to do more
than just store; we'd actually drop the credential entirely (and maybe
even cause the daemon to exit) if it expires before the usual timeout.
next prev parent reply other threads:[~2022-11-14 22:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-24 7:57 [PATCH] docs: clarify that credential discards unrecognised attributes M Hickford via GitGitGadget
2022-10-24 23:59 ` Jeff King
2022-10-25 0:00 ` Jeff King
2022-10-25 1:51 ` Thanks M Hickford
2022-10-25 9:05 ` Thanks Bagas Sanjaya
2022-10-26 4:39 ` Thanks M Hickford
2022-10-26 5:18 ` Thanks Jeff King
2022-10-26 9:36 ` Thanks Junio C Hamano
2022-11-12 2:21 ` [PATCH] docs: clarify that credential discards unrecognised attributes M Hickford
2022-11-12 16:47 ` Jeff King
2022-11-12 19:08 ` M Hickford
2022-11-14 22:40 ` Jeff King [this message]
2022-11-13 4:56 ` Taylor Blau
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).