Problem
The Touch ID integration should skip re-authenticating when the keychain is already unlocked, and unlock it when it isn't. Right now there's no way to check which state we're in, so we're stuck picking between two bad options: cache "already authenticated" locally and skip re-checking (goes stale the moment the keychain re-locks on its own, e.g. auto-lock or sleep, silently falling back to the system password prompt we're trying to avoid), or always re-run the unlock flow regardless of current state (a Touch ID prompt on every call, even when unnecessary).
What's needed
A read-only, side-effect-free way to ask "is this keychain unlocked right now" using the OS's own lock state, not an assumption we track ourselves.
Question
Does anyone know why ByteNess/keyring depends ByteNess/go-keychain@8e49817e8af4 while https://github.com/ByteNess/go-keychain/tree/main depends on the revision older than ByteNess/go-keychain@8e49817e8af4?
Problem
The Touch ID integration should skip re-authenticating when the keychain is already unlocked, and unlock it when it isn't. Right now there's no way to check which state we're in, so we're stuck picking between two bad options: cache "already authenticated" locally and skip re-checking (goes stale the moment the keychain re-locks on its own, e.g. auto-lock or sleep, silently falling back to the system password prompt we're trying to avoid), or always re-run the unlock flow regardless of current state (a Touch ID prompt on every call, even when unnecessary).
What's needed
A read-only, side-effect-free way to ask "is this keychain unlocked right now" using the OS's own lock state, not an assumption we track ourselves.
Question
Does anyone know why
ByteNess/keyringdepends ByteNess/go-keychain@8e49817e8af4 while https://github.com/ByteNess/go-keychain/tree/main depends on the revision older than ByteNess/go-keychain@8e49817e8af4?