After TB update to 60.7.0 Enigmail enters infinite loop

[James M. Moe]

Thunderbird 60.7.0
Enigmail 2.0.11 (23-May-2019)
linux 4.12.14-lp150.12.64-default x86_64

TB was updated today to 60.7.0 from 60.6.0.

Enigmail starts consuming 40% of a quad CPU's resource after a message is loaded that may require Enigmail's services. Selecting "View Console" or "View Log" results in the same CPU usage, without displaying anything.

The CPU usage drops to normal (1 - 3%) after disabling Enigmail.

Suggestions for debugging this?

[Patrick Brunschwig]

The JavaScript engine in Thunderbird is single-threaded. It's therefore not possible for Enigmail to consume more than 1 single CPU. The first thing you should check is: is it really Enigmail (i.e. the Thunderbird binary) or something like gpg that consumes the CPU?

[James M. Moe]

On 22/06/2019 1.54 AM, Patrick Brunschwig wrote:

The first thing you should check is: is it really Enigmail (i.e. the
Thunderbird binary) or something like gpg that consumes the CPU?

My mistake about the CPU usage. It is about 28%; the runaway process
plus everything else.
Top show that "gpg2" is running hot, not TB.
Disabling Enigmail stops whatever is running amok, though.

--
James Moe
moe dot james at sohnen-moe dot com
520.743.3936
Think.

[Patrick Brunschwig]

Then the problem is really gpg2, not enigmail.

Try on a command line to list a key or encrpt or decrypt a message. I suspect that you'll see the same behavior - but hopefully also some error message.

[James M. Moe]

On 22/06/2019 2.43 PM, Patrick Brunschwig wrote:

Try on a command line to list a key

$ gpg2 -v --list-keys
gpg: using pgp trust model
gpg: checking the trustdb
gpg: public key algorithm ELG not suitable for signing
gpg: public key algorithm ELG not suitable for signing
<many, many="" more="" of="" the="" above="" line="">
gpg: public key algorithm ELG not suitable for signing
^C
gpg: signal Interrupt caught ... exiting</many,>

--
James Moe
moe dot james at sohnen-moe dot com
520.743.3936
Think.

[Patrick Brunschwig]

I'm not sure what precisely goes wrong here. I think there is a problem with a specific key, that causes gpg to loop endlessly.

I'd try: gpg2 --debug-all --list-keys and report the outcome to the gnupg users mailing list together with the precise gpg version you're using.