Gpg blocking forever, can't `git commit` as a result

I just installed Fedora 39 and configured the same way I had running in previous versions. While most of the things “mostly work”, I have a huge blocker right now: I can’t git commit! It’s a crucial part of my job, and I’m not sure what’s wrong or even how to debug it.

I was able to track it down to gpg (as I sign my commits, just like you!), which blocks forever when running this:

> gpg -vk
gpg: enabled compatibility flags:
gpg: using pgp trust model

This started happening for all calls out of a sudden and persists after reboot, and I can’t determine what’s the trigger for this. I already tried to start over and install F39 again, but eventually got into the same problem.

I can’t seem to be able to find logs for what’s going on anywhere, and using -v gets me only the output I’ve shared. Any ideas on what’s going on?

1 Like

Hi @jpkroehling , welcome to the forum.

This is a weird one. It seems to work fine for me here, no issues with running gpg -vk at all:

$ gpg -vk
gpg: enabled compatibility flags:
gpg: using pgp trust model
/home/asinha/.gnupg/pubring.kbx
-------------------------------

...

What steps did you take to configure your keys? Maybe something has changed in the newer versions of gpg that’s causing the issue?

Let’s also try to get more info. I see the man page specifies the --debug-level option, so maybe we could try:

gpg -vvv -k --debug-level guru --debug-all

and see if that says anything?

1 Like

Hi!

Seconding what @ankursinha said. I think it’s worthwhile to find out if some external resource blocks gpg here, or if it’s a bug in the program itself.

One tool I use to find this out is strace, which tells you the system calls a program does when it executes. If the examined program say waits for a reply of an external server, it’s often obvious in the strace output (if you know how to interpret it).

1 Like

Just to clarify: gpg (and git commit) did work before on this Fedora 39. Something I installed or did caused it to stop working.

In any case, here’s the output for the command you provided:

> gpg -vvv -k --debug-level guru --debug-all

gpg: reading options from '[cmdline]'
gpg: reading options from '/home/jpkroehling/.gnupg/common.conf'
gpg: using character set 'utf-8'
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: enabled compatibility flags:
gpg: DBG: [no clock] start
gpg: using pgp trust model
1 Like

And here are the results for strace:

read(3, "\1gpg\3\3\1\5\1\2\0\0e[y\237\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 40) = 40
openat(AT_FDCWD, "/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libgpg-error.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US.utf8/LC_MESSAGES/libgpg-error.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/libgpg-error.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.UTF-8/LC_MESSAGES/libgpg-error.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en.utf8/LC_MESSAGES/libgpg-error.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/libgpg-error.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
getuid()                                = 1000
newfstatat(AT_FDCWD, "/run/user/1000", {st_mode=S_IFDIR|0700, st_size=600, ...}, 0) = 0
getuid()                                = 1000
newfstatat(AT_FDCWD, "/run/user/1000/gnupg", {st_mode=S_IFDIR|0700, st_size=60, ...}, 0) = 0
getuid()                                = 1000
newfstatat(AT_FDCWD, "/run/user/1000/gnupg/S.keyboxd", {st_mode=S_IFSOCK|0700, st_size=0, ...}, 0) = 0
socket(AF_UNIX, SOCK_STREAM, 0)         = 4
newfstatat(AT_FDCWD, "/run/user/1000/gnupg/S.keyboxd", {st_mode=S_IFSOCK|0700, st_size=0, ...}, 0) = 0
connect(4, {sa_family=AF_UNIX, sun_path="/run/user/1000/gnupg/S.keyboxd"}, 32) = 0
recvmsg(4, 

And it just hangs there.

strace actually helped me get further: searching for more info about “keyboxd”, I came across this:

Commenting out “use-keyboxd” from ~/.gnupg/common.conf make it work again for me. Interestingly, I don’t remember creating this file myself, and I don’t seem to have my keys there anymore. Perhaps some package had my ~/.gnupg overridden? In any case, it’s all working now.

1 Like

I found this in the readme in the GitHub repo:


** Key database daemon

  Since version 2.3.0 it is possible to store the keys in an SQLite
  database instead of the keyring.kbx file.  This is in particular
  useful for large keyrings or if many instances of gpg and gpgsm may
  run concurrently.  This is implemented using another daemon process,
  the "keyboxd".  To enable the use of the keyboxd put the option
  "use-keyboxd" into the configuration file ~/.gnupg/common.conf or the
  global /etc/gnupg/common.conf.  See also doc/examples/common.conf.
  Only public keys and X.509 certificates are managed by the keyboxd;
  private keys are still stored as separate files.

  Since version 2.4.1 the keyboxd will be used by default for a fresh
  install; i.e. if a ~/.gnupg directory did not yet exist.

  Note that there is no automatic migration; if the use-keyboxd option
  is enabled keys are not taken from pubring.kbx.  To migrate existing
  keys to the keyboxd do this:

  1. Disable the keyboxd (remove use-keyboxd from common.conf)
  2. Export all public keys
       gpg --export --export-options backup  > allkeys.gpg
       gpgsm --export --armor                > allcerts.gpg
  3. Enable the keyboxd (add use-keyboxd to common.conf)
  4. Import all public keys
       gpg --import --import-options restore < allkeys.gpg
       gpgsm --import                        < allcerts.crt

I also see this bug that may be the same issue:

https://bugzilla.redhat.com/show_bug.cgi?id=2249218

If you can reliably reproduce it, I’d file a bug. There’s maybe something off with the keyboxd bit—perhaps it isn’t running properly or there are other issues?

I looked at the bug and I think it’s the same issue.

1 Like