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

quoted

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