Re: [PATCH] osxkeychain: lock for exclusive execution

From: Junio C Hamano <gitster@pobox.com>
Date: May 10, 2024, 20:40 UTC
Message-ID: <xmqqh6f54czm.fsf@gitster.g>
In-Reply-To: <20240510200114.GC1954863@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 11 quoted lines

>   - 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.