Timout for gpg-agent related operations like: decrypt a message
OpenPGP addon for Mozilla Thunderbird
Brought to you by:
pbrunschwig
I am running a freshly installed Ubuntu 15.10 using GnuPG 2.0.28 and Thunderbird 38.3.0 using Enigmail 1.8.2.
All operations that access the gpg-agent seem to run into a timeout and for this reason they are very slow. This means that signing, decrypting, encrypting take additional ~25 seconds in order to be performed.
One specific example:
This behaviour is exactely the same if I jump to another unencrypted email in my inbox and afterwards back to the encrypted one.
There seems to be a timeout with the gpg-agent because the Enigmail log says for the example above:
Initializing Enigmail service ...
EnigmailAgentPath=/usr/bin/gpg2
enigmail> /usr/bin/gpg2 --version --version --batch --no-tty --charset utf-8 --display-charset utf-8
gpg (GnuPG) 2.0.28
libgcrypt 1.6.3
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://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: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA, RSA, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
enigmail> /usr/bin/gpg2 --charset utf-8 --display-charset utf-8 --batch --no-tty --status-fd 2 --max-output 319000 --decrypt --use-agent
enigmail> /usr/bin/gpg2 --charset utf-8 --display-charset utf-8 --batch --no-tty --status-fd 2 --fixed-list-mode --with-colons --list-keys ABCDEFGHIJK12345
I installed language support for German at the whole system and after doing this the delay is gone. I do not have a clue what is the reason for that....
This seems to be a distribution-specific problem. If you want to contribute, then please post this at a Ubuntu support forum. Thanks :-)
On Sun 2015-11-15 15:19:20 -0500, Uwe Kaminski wrote:
fwiw, I think this timeout is due to pinentry-gtk waiting on some dbus
accessibility (a11y) service (/org/a11y/bus, maybe?), and timing out
after 250000 milliseconds.
I have been unable to reproduce it myself, but i've seen straces from
users with similar reports.
--dkg