Hi Jack: Am 31.07.17 00:05 schrieb(en) Jack:
Today, I found I had a few messages which, when selected, simply froze Balsa for something like 30 seconds. I finally noticed (if I just waited and didn't already click on three other things) that there was an error from gpg2, trying to fetch the key from pgp.mit.edu. Manually invoking gpg2 from command line had the same delay and error message, thus I know the problem is not really in Balsa. Lots of Googling led me to add the line "standard-resolver" to ~/.gnupg/dirmngr.com, and then kill the currently running dirmngr process. Although that particular key returned "no data", at least it now does so immediately, without the delay (timeout?) Is this a known problem? Is it something I should bring up with my distro, or directly with gnupg/dirmngr upstream? All the posts I did find refered to older versions of gnupg, I'm now on 2.1.20.
I use an older GnuPG version (2.1.11), so I'm not sure if this is helpful for you... Do you have the option “auto-key-retrieve” activated in your ~/.gnupg/gpg.conf file? Quoting from the man page: <snip> auto-key-retrieve This option enables the automatic retrieving of keys from a keyserver when verifying signatures made by keys that are not on the local keyring. Note that this option makes a "web bug" like behavior possible. Keyserver operators can see which keys you request, so by sending you a message signed by a brand new key (which you naturally will not have on your local keyring), the operator can tell both your IP address and the time when you verified the signature. </snip> This might explain the behaviour you observed. In general I would recommend to disable this option, and to launch the key download from Balsa manually. The latter is performed fully in background (in a separate thread), thus not blocking Balsa. You have to re-check the message after a successful key download as to verify the signature, though. Hope this helps, Albrecht.
Attachment:
pgpAo32yTJY4f.pgp
Description: PGP signature