roddhjav
commented
4 weeks ago That is a tricky one.
To sum up the issue,
- Upon need, GPG start a new gpg-agent daemon to handle keyring for each keyring (
~/.gnupg,/etc/apt/trusted.gpg.d/,/etc/pacman.d/gnupg/, any other user keyring you have). - The default gpg-agent has access to most keyrings (ideally it should be limited to only the user's one (so
~/.gnupg). So the first time you use gpg, it should be ok. - Other agent can be started with different keyring under a different profile (eg:
pacman//gpg) - Sometime a program (in this example, lazygit) can use a gpg-agent that run under a profile that prevent access to the actual needed keyring.
- It is a pain to debug
I currently don't know how to fix this in a correct way.
Not sure which profile causes this as setting gpg* to complain doesn't fix this. I encountered this with lazygit and was unable to commit until a teardown. Logs don't show anything, just this from journalctl:
gpg-agent[58120]: command 'PKSIGN' failed: No pinentry gpg-agent[58120]: failed to read the secret key gpg-agent[58120]: failed to unprotect the secret key: No pinentry gpg-agent[58120]: can't connect to the PIN entry module '/usr/bin/pinentry': End of file gpg-agent[58120]: SIGHUP received - re-reading configuration and flushing cache