Control: fixed -1 1:52.8.0-1 For a couple of days now, thunderbird doesn't exhibit those symptoms anymore, and I was able to let an instance sitting on a workspace for two whole days without having the CPU go crazy.
Note that according to APT history log, Thunderbird was upgraded from 1:52.7.0-1 to 1:52.8.0-1 on May 20, which matches the disappearance of the symptoms. I initially had a doubt about which package to file the report against (Thunderbird or Enigmail), but it seems that my guess was right after all (it can't be a coincidence since there were no GnuPG or Enigmail update on that day). On the other hand, Enigmail now fails to automatically retrieve **any** signature from the key server, and displays a yellow header with the "Import key" button, which can't import the key either. After manually downloading the key (from command line), Enigmail is able to correctly verify the signature and a green header is displayed, which indicates that the problem indeed lies in the communication between Enigmail and the key server. I tried to change the key server option in Enigmail's preferences from "pool.sks-keyservers.net" to "hkps.pool.sks-keyservers.net", to "hkps://hkps.pool.sks-keyservers.net", to "pgp.mit.edu", but it made no difference. The gpg command used by Enigmail is: /usr/bin/gpg --charset utf-8 --display-charset utf-8 --no-auto-check-trustdb --batch --no-tty --status-fd 2 --keyserver-options auto-key-retrieve --keyserver pool.sks-keyservers.net --sender <some email address> --verify /tmp/data.sig By copying file /tmp/data.sig before it's deleted, and trying to run the very same command line on the copied file, I get this: gpg: no signed data gpg: can't hash datafile: No data So this bug report can be closed (no more random key fetching nor abnormal CPU consumption) but a new bug appeared. What else can I do to help debugging this ? Regards, -- Raphaël Halimi
signature.asc
Description: OpenPGP digital signature
