Re: [PATCH] osxkeychain: lock for exclusive execution

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux