Re: [PATCH v7 00/12] Enhance credential helper protocol to include auth headers

From: Jeff King <peff@peff.net>
Date: Feb 2, 2023, 00:16 UTC
Message-ID: <Y9sAysjR8jCbETxy@coredump.intra.peff.net>
In-Reply-To: <AS2PR03MB9815DEDEA3CF40F3D54624E0C0D19@AS2PR03MB9815.eurprd03.prod.outlook.com>

On Wed, Feb 01, 2023 at 12:15:17PM -0800, Matthew John Cheetham wrote:

Show 12 quoted lines

> > Challenge responses are typically short lived [1]. What happens if a storage helper is configured before a challenge-response helper? We want to maintain composability of helpers.
> > 
> > [credential]
> >     helper = storage  # eg. cache or osxkeychain
> >     helper = challenge-response  # eg. oauth-dpop
> 
> I think really this sort of thing is where the credential helper protocol
> isn't designed for credential-generating helpers in mind, but only simple
> storage-only helpers. There is no affinity between get/erase/store commands
> meaning one helper may return a credential for another helper to store it.
> Not sure if this was ever the intention, over just the need to consult a
> list of helpers for a stored credential.

I actually had envisioned helpers generating credentials. In fact, in the first iteration of the series, Git did not prompt for passwords at all! It would depend on git-credential-prompt to do so. But I ended up folding that in for simplicity.

I could well believe that there is not enough context passed around for helpers to make good decisions, though. It's both a feature and a bug that credentials from one helper get passed to another. It's good if you want to cache a generated credential. It's bad if you don't want credentials from one helper to leak to another, less-secure one.

So I'm open to improvements that help define and communicate that context.

-Peff