After any command to list or edit keys, the command is stuck (I waited for over a minute for anything to be printed). The $HOME/.gnupg folder is populated and a few days ago I successfully imported two keys! Could you tell me what I have to do to troubleshoot this? I am quite worried.
$ gpg --help
gpg (GnuPG) 2.4.3
libgcrypt 1.10.2-unknown
Copyright (C) 2023 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: /home/tommi/.gnupg
Errors
$ gpg --list-secret-keys --verbose
gpg: enabled compatibility flags:
gpg: using pgp trust model
^C
$ gpg --list-keys --verbose
gpg: enabled compatibility flags:
gpg: using pgp trust model
^C
gpg --verbose --edit-key C25EBAA6557EEE9F72A574B9B045212E435C7A80
gpg (GnuPG) 2.4.3; Copyright (C) 2023 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gpg: enabled compatibility flags:
^C
gpg: signal Interrupt caught ... exiting
Adding --verbose or even --debug-level basic to the command might also help to explain where it is stuck. Might be related to the new keyboxd if you started with a fresh gnupg home directory. In that case you could comment out use-keyboxd in ~/.gnupg/common.conf but then you will start with an empty public keyring.
Unfortunately, after running gpgconf -K gpg-agent or gpgconf -R gpg-agent nothing changes… after rebooting, I see waiting for lock (held by 20) ...
$ gpg --list-keys
gpg: waiting for lock (held by 20) ...
gpg: waiting for lock (held by 20) ...
gpg: waiting for lock (held by 20) ...
^C
gpg: signal Interrupt caught ... exiting
After doing what you suggested, I get:
$ gpg --list-keys --verbose
gpg: enabled compatibility flags:
gpg: keybox '/home/tommi/.gnupg/pubring.kbx' created
gpg: using pgp trust model
I ran into this problem, and landed here looking for a solution.
Reading through that even a reinstall did not change the behavior I surmised there must be some kind of lock file, persisting the lock state in the filesystem.
For me the fix was to rm ~/.gnupg/{S.keyboxd,public-keys.d/pubring.db.lock}
in alpine I did not have to restart gpg-agent again after this, but it may be helpful to do so after removing the lockfiles: gpgconf -R gpg-agent
I do not know why nobody answered again to Tommi last year but, extrapolating from myself, probably to much else to do and no definitive answer…
For Tommi I would guess the cause of the not accessible lock files was that Fedora AFAIK uses systemd to start the gpg-agent, which can lead to issues with inaccessible lock files or sockets. Deleting those - like you did - would solve the problem for the moment but it may recur. Although likely not often, otherwise more people would complain
Needless to say, using systemd is not the way recommended by the gpg developers to start gpg-agent. Unfortunately several Linux distributions do it.
AFAIK Alpine is an exception though. How does Alpine start gpg-agent? Maybe a logind?
It seems anyway you did not start it by using gpg, as then the socket would have been in /run/user/UID not in your GPGHOME.