gnupg 2.3.2 with libgcrypt 1.9.4 on latest OpenIndiana (one of the Illumos distros that came out of the OpenSolaris project).
When running gpg2 on OpenIndiana, it appears there's some kind of issue communicating over the socket with gpg-agent.
With no gpg-agent running and GPG_TTY correctly set, if I attempt to decrypt a file that was encrypted to me on a different machine, via
$ gpg2 --version gpg (GnuPG) 2.3.2 libgcrypt 1.9.4 Copyright (C) 2021 Free Software Foundation, Inc. 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: /faculty/ndsu/mooney/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 AEAD: EAX, OCB Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 $ gpg2 --decrypt /tmp/textfile.txt.asc
what happens is that the gpg-agent is started:
$ ps -ef | egrep gpg-agent mooney 15182 1 0 13:38:49 ? 0:00 gpg-agent --homedir /faculty/ndsu/mooney/.gnupg --use-standard-socket --daemon
but instead of the expected pinentry display, I get a blank screen, with my cursor in roughly the center of the terminal window, in what must be the location of an "invisible" pinentry box.
I can type in the invisible pinentry display, and if I correctly type my passphrase and hit enter, the invisible pinentry screen goes away and I see:
gpg: encrypted with elg1024 key, ID 100A77F8477C6C9C, created 2001-03-15 "Tim Mooney (NDSU ITS) <Tim.Mooney@ndsu.edu>"
at which point gpg is hung.
If I attach to the running process with truss (the Solaris system call tracer, similar to Linux's strace), I see:
$ ps -ef | grep -i gpg mooney 15200 1 13 13:44:07 ? 2:16 gpg-agent --homedir /faculty/ndsu/mooney/.gnupg --use-standard-socket --daemon mooney 15198 3614 0 13:44:07 pts/5 0:00 gpg2 --decrypt /tmp/textfile.txt.asc $ truss -f -p 15198 15198: read(6, 0x011EF2F0, 1002) (sleeping...)
fd 6 that it's trying to read() from appears to be the socket for communicating with gpg-agent.
While this is going on, gpg-agent starts accumulating CPU time at at rapid rate.
Whatever is happening with gpg-agent, it can't be killed normally. Trying to use 'gpgconf --kill gpg-agent' hangs, and 'kill -TERM' fails to kill it. Only 'kill -9' will actually kill it.
Note that it's not just a decrypt operation that hangs. It seems like any operation that requires communication with the gpg-agent will hang at some point.
Even though the pinentry interaction didn't correctly display anything, I don't think the problem is with pinentry. When I run 'pinentry-gkt-2' or 'pinentry-curses' directly, and issue the correct "assuan" protocol "commands" to either of the pinetry programs, when GETPIN is issued they correctly draw the curses-based dialog and they respond with the test password I entered.
It seems like the issue has something to do with communication between gnupg and gpg-agent, but I'm not certain what the issue is.
I can run additional tests, if you can provide some guidance on what debugging options or tests should be investigated.