On Fri, May 10, 2024 at 01:40:29PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > - we could remember _which_ helper we got the credential from, and > > avoid invoking it again. > > > > - we could record a bit saying that the credential came from a helper, > > and then feed that back to helpers when storing. So osxkeychain > > could then decide not to store it. > > > > Both of those solve the repeated stores, but still let credentials > > populate across helpers (which I still think is a questionable thing to > > do by default, per the discussion in that thread, but is the very thing > > that some people rely on). > > Would "refreshing the last-time-used record" a valid use case for > the behaviour that feeds the successful one back to where the > credential came from? Such a helper could instead log the last-time > the credential was asked for, and assume that the lack of an explicit > "reject" call signals that the use of the value it returned earlier > was auccessfully used, but it is a less obvious way to implement > such a "this hasn't been successfully used for a long time, perhaps > we should expire/ask again/do something else?" logic. There was some discussion in that old thread about whether that was important or not. I don't have a strong opinion there. Not refreshing is a more secure default, but possibly more annoying (and a change from the status quo). I do think brian's suggestion to use state[] to pass it back means that the decision is then in the hands of the helper. So "credential-cache", for example, could decide whether to refresh its ttl or not, or we could even make it configurable with a command-line option for the helper. -Peff
