Solved gpg-agent hanging indefinitely after upgrade to FreeBSD 14.0

E

enumeration

Hi all,

I recently started experiencing problems with GnuPG on my FreeBSD system, and they temporally correlate with the upgrade to 14.0 (however I cannot say for sure that's when it started).
I'm not sure this is the perfect place to ask, but maybe someone has any hints for further debugging.

The problem: Whenever I try to decrypt a file with gpg --decrypt, or sign with gpg --sign, the program just hangs indefinitely.

What I tried:
  • Increasing verbosity:
    sh: 
    % gpg -vvvvvvvv --sign exampledocument.pdf
gpg: using character set 'US-ASCII'
gpg: enabled compatibility flags:
[indefinite hang]
  • Trying another pinentry implementation and increasing verbosity by editing gpg-agent.conf:
    Code: 
    pinentry-program /usr/local/bin/pinentry-gtk-2
debug-pinentry
debug-level 1024
    (all of pinentry-curses, pinentry-gtk-2 and pinentry-qt5 are installed - same problem with each of them - yes, i did pkill gpg-agent after each edit)
  • Running gpg-agent manually with debug options, then concurrently trigger gpg -vvvvvvvv --sign exampledocument.pdf
    sh: 
    % gpg-agent -vvvvvv --debug --daemon
gpg-agent[37384]: Optionen werden aus '/home/enum/.gnupg/gpg-agent.conf' gelesen
gpg-agent[37384]: Optionen werden aus '[cmdline]' gelesen
gpg-agent[37384]: enabled debug flags: mpi crypto memory cache memstat ipc
  • I even created a new thick jail (fbsd14.0), copied the .gnupg directory over, tried it over there. The problem is only getting weirder:
    sh: 
    $ touch x
$ gpg --sign x
gpg: Warning: using insecure memory!
gpg: signing failed: No such file or directory
gpg: signing failed: No such file or directory
    gpg --list-keys and --list-secret-keys do list the matching key.
Versions:
  • gpg / gpg-agent 2.4.3
  • libgcrypt 1.10.3
  • pinentry-curses / pinentry-gtk-2 / pinentry-qt5 1.2.1
I really don't know what to try any more. Any debugging ideas are appreciated.
Is there any global configuration file that I might be overlooking? Any important directories, sockets, log files?
 
Any chance you have your private key on a smartcard/yubikey? If yes, downgrade to gnupg 2.3.3 because all later versions are broken with smartcards and/or gpg-agent. upstream bug reports have been unanswered or closed without any fix, hence I still build v2.3.3 via poudriere for all my systems...
 
samjenk said:
Have you tried running top(1) in another terminal while the process is hanging to see what resources it's using? You might also try running truss(1) when you start the process to see what it's getting tripped up on.
Click to expand...
Good idea! This is what I found out:
  • according to top, gpg-agent -vvvvv --debug --daemon is waiting for a socket all the time - though I think this is what it's supposed to do, and the resource consumption seems legitimate:
    Code: 
    11088 enum          1  60    0    15M  4772K sbwait   4   0:00   0.00% gpg-agent
  • the exact same goes for gpg2 though - that one is also waiting for a socket, probably for an answer from gpg-agent I suppose.
    Code: 
    35385 enum          1  28    0    18M  7736K sbwait   4   0:00   0.00% gpg2
  • according to truss gpg-agent --debug -vvvvv --daemon gpg-agent is listening on /var/run/user/1001/gnupg/S.gpg-agent. These are the last lines:
    Code: 
    socket(PF_LOCAL,SOCK_STREAM,0)                   = 3 (0x3)fstatat(AT_FDCWD,"/var/run/user/1001/gnupg/S.gpg-agent",{ mode=srwx------ ,inode=1343706,size=0,blksize=131072 },0x0) = 0 (0x0)
bind(3,{ AF_UNIX "/var/run/user/1001/gnupg/S.gpg-agent" },38) ERR#48 'Address already in use'
fstatat(AT_FDCWD,"/var/run/user/1001/gnupg/S.gpg-agent",{ mode=srwx------ ,inode=1343706,size=0,blksize=131072 },0x0) = 0 (0x0)
socket(PF_LOCAL,SOCK_STREAM,0)                   = 4 (0x4)
fstatat(AT_FDCWD,"/var/run/user/1001/gnupg/S.gpg-agent",{ mode=srwx------ ,inode=1343706,size=0,blksize=131072 },0x0) = 0 (0x0)
connect(4,{ AF_UNIX "/var/run/user/1001/gnupg/S.gpg-agent" },38) = 0 (0x0)
    At some point there's an "ERR#48 Adress is already in use", so I tried to find out what's using the socket, but the list is empty:
    Code: 
    % sudo fstat -vs /var/run/user/1001/gnupg/S.gpg-agent
USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W NAME
    Am I doing something wrong here?
  • then I started truss gpg2 -vvvvvvvv --sign Untitled\ 1.odt, the last lines being:
    Code: 
    fstatat(AT_FDCWD,"/run/user/1001",0x821091ba0,0x0) ERR#2 'No such file or directory'getuid()                                         = 1001 (0x3e9)
fstatat(AT_FDCWD,"/var/run/user/1001",{ mode=drwx--S--- ,inode=983311,size=11,blksize=131072 },0x0) = 0 (0x0)
getuid()                                         = 1001 (0x3e9)
fstatat(AT_FDCWD,"/var/run/user/1001/gnupg",{ mode=drwx--S--- ,inode=1006294,size=7,blksize=131072 },0x0) = 0 (0x0)
getuid()                                         = 1001 (0x3e9)
fstatat(AT_FDCWD,"/var/run/user/1001/gnupg/S.gpg-agent",{ mode=srwx------ ,inode=1343706,size=0,blksize=131072 },0x0) = 0 (0x0)
socket(PF_LOCAL,SOCK_STREAM,0)                   = 3 (0x3)
fstatat(AT_FDCWD,"/var/run/user/1001/gnupg/S.gpg-agent",{ mode=srwx------ ,inode=1343706,size=0,blksize=131072 },0x0) = 0 (0x0)
connect(3,{ AF_UNIX "/var/run/user/1001/gnupg/S.gpg-agent" },38) = 0 (0x0)
    Nothing suspicious here from my view.
  • However, running the gpg2 command did not trigger any reaction or change in the gpg-agent process. No new system calls.

sko said:
Any chance you have your private key on a smartcard/yubikey? If yes, downgrade to gnupg 2.3.3 because all later versions are broken with smartcards and/or gpg-agent. upstream bug reports have been unanswered or closed without any fix, hence I still build v2.3.3 via poudriere for all my systems...
Click to expand...
There are no smartcards or yubikeys involved in any manner. Also, none are set up or connected. The keys are files in ~/.gnupg.
 
New update! After I decided to rm /var/run/user/1001/gnupg/S.gpg-agent (I still don't know what occupied it), the output was quite different:
Code: 
% gpg-agent --debug -vvvvv --daemon                                                                                                                                                                                      
gpg-agent[26220]: Optionen werden aus '/home/enum/.gnupg/gpg-agent.conf' gelesen
gpg-agent[26220]: Optionen werden aus '[cmdline]' gelesen
gpg-agent[26220]: enabled debug flags: mpi crypto memory cache memstat ipc
gpg-agent[26220]: Es wird auf Socket `/var/run/user/1001/gnupg/S.gpg-agent' gehört
gpg-agent[26220]: Es wird auf Socket `/var/run/user/1001/gnupg/S.gpg-agent.extra' gehört
gpg-agent[26220]: Es wird auf Socket `/var/run/user/1001/gnupg/S.gpg-agent.browser' gehört
gpg-agent[26220]: Es wird auf Socket `/var/run/user/1001/gnupg/S.gpg-agent.ssh' gehört
gpg-agent[26530]: gpg-agent (GnuPG) 2.4.3 started
peridot/enum: ~ % gpg-agent[26530]: DBG: agent_cache_housekeeping
gpg-agent[26530]: DBG: agent_cache_housekeeping
gpg-agent[26530]: DBG: agent_cache_housekeeping
gpg-agent[26530]: DBG: agent_cache_housekeeping
gpg-agent[26530]: DBG: chan_7 -> OK Pleased to meet you
gpg-agent[26530]: DBG: chan_7 <- RESET
gpg-agent[26530]: DBG: chan_7 -> OK
gpg-agent[26530]: DBG: chan_7 <- OPTION ttyname=/dev/pts/3
gpg-agent[26530]: DBG: chan_7 -> OK
gpg-agent[26530]: DBG: chan_7 <- OPTION ttytype=xterm-256color
gpg-agent[26530]: DBG: chan_7 -> OK
gpg-agent[26530]: DBG: chan_7 <- OPTION display=:0
gpg-agent[26530]: DBG: chan_7 -> OK
gpg-agent[26530]: DBG: chan_7 <- OPTION putenv=WAYLAND_DISPLAY=wayland-1
gpg-agent[26530]: DBG: chan_7 -> OK
gpg-agent[26530]: DBG: chan_7 <- OPTION putenv=XDG_SESSION_TYPE=wayland
gpg-agent[26530]: DBG: chan_7 -> OK
gpg-agent[26530]: DBG: chan_7 <- GETINFO version
gpg-agent[26530]: DBG: chan_7 -> D 2.4.3
gpg-agent[26530]: DBG: chan_7 -> OK
gpg-agent[26530]: DBG: chan_7 <- OPTION allow-pinentry-notify
gpg-agent[26530]: DBG: chan_7 -> OK
gpg-agent[26530]: DBG: chan_7 <- OPTION agent-awareness=2.1.0
gpg-agent[26530]: DBG: chan_7 -> OK
gpg-agent[26530]: DBG: chan_7 <- SCD SERIALNO
gpg-agent[26530]: no running /usr/local/libexec/scdaemon daemon - starting it
gpg-agent[26530]: DBG: agent_flush_cache (pincache only)
gpg-agent[26530]: DBG: chan_8 <- OK GNU Privacy Guard's Smartcard server ready
gpg-agent[26530]: first connection to daemon /usr/local/libexec/scdaemon established
gpg-agent[26530]: DBG: chan_8 -> GETINFO socket_name
gpg-agent[26530]: DBG: chan_8 <- D /var/run/user/1001/gnupg/S.scdaemon
gpg-agent[26530]: DBG: chan_8 <- OK
gpg-agent[26530]: DBG: additional connections at '/var/run/user/1001/gnupg/S.scdaemon'
gpg-agent[26530]: DBG: chan_8 -> OPTION event-signal=31
gpg-agent[26530]: DBG: chan_8 <- OK
gpg-agent[26530]: DBG: chan_8 -> SERIALNO
gpg-agent[26530]: DBG: agent_cache_housekeeping
gpg-agent[26530]: DBG: agent_cache_housekeeping
gpg-agent[26530]: DBG: agent_cache_housekeeping

So, this time, gpg-agent did receive the commands from gpg2, but still no result oder error message - gpg2 keeps hanging.
But after sko's comment on smartcards, the lines mentioning scdaemon seem suspicious. So I added the following to .gnupg/gpg-agent.conf:
Code: 
disable-scdaemon

And after that, it worked! Thanks a lot, I wouldn't have found this without both your comments!
 
sko said:
Any chance you have your private key on a smartcard/yubikey? If yes, downgrade to gnupg 2.3.3 because all later versions are broken with smartcards and/or gpg-agent. upstream bug reports have been unanswered or closed without any fix, hence I still build v2.3.3 via poudriere for all my systems...
Click to expand...
Is this still an issue - I have been looking for more information related to this but can't seem to find anything. Do you by chance have a link to more info regarding version being broken?
 
Yes, it is still an issue - gnupg folks broke their scdaemon after 2.3.3 and won't fix it. Their "fix" for the endless freezing/blocking when trying to access the smartcard was to completely ignore the smartcard/yubikey...

However, I found a solution a while ago which works with newer gnupg versions.
You have to use devel/pcsc-lite for accessing GPG-keys on smartcards now and prevent gnupgs broken scdaemon from blocking the card by adding "pcsc-shared" and "disable-ccid" to ~/.gnupg/scdaemon.conf.

Depending on the yubikey version you might also need to enable hidraw and usbhid support so pcscd can access the smartcard via hidraw. This is done via the following settings in /boot/loader.conf:
Code: 
hidraw_load="YES"
hkbd_load="YES"
hw.usb.usbhid.enable="1"
 
You must log in or register to reply here.
Back
Top