On Wed, Feb 01, 2023 at 12:15:17PM -0800, Matthew John Cheetham wrote: > > 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
