Unlock the login keyring at login and keep the GPG passphrase cached #108
Labels
No labels
approved
bug
changes-requested
ci
decision
declined
discuss
docs
feature
meta
now
packaging
refactor
release
repo/core
repo/krystal
repo/plugins
repo/themes
status/backlog
status/in-progress
status/next
status/review
ux
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
joshquinlan/donbox#108
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Every login shows a keyring-not-unlocked message and gpg asks for the passphrase again on the first signed commit. Diagnose which keyring (gnome-keyring secrets via PAM, or the GPG agent cache) is not unlocked by the greeter: wire pam_gnome_keyring into the login and greeter PAM stack (tuigreet/greetd) so the login password unlocks it, start gnome-keyring-daemon in the session with the secrets component, and set gpg-agent default-cache-ttl and max-cache-ttl to session length with the passphrase stored in the keyring via pinentry; confirm with a signed commit after a fresh login.
Diagnosed and built on the keyring branch (b74ac4e), awaiting a decision before it goes on master. Neither keyring is broken: greetd already runs pam_gnome_keyring, but system-auth puts pam_fprintd first as sufficient, so a fingerprint login never hands a password to the keyring (journal: "gkr-pam: no password is available for user", grantors=pam_fprintd). The fix in install/25-keyring switches the greeter stack to password-auth, which means typing the password at tuigreet instead of a finger; sudo and polkit keep the reader. No third option exists with authselect. gpg-agent already caches for 28800 s; the first signed commit of a session prompts once by design, now through the Donbox pane. Say here whether to take the trade-off.