Bug 1039471 - Update to Thunderbird 52 breaks Enigmail decryption of e-mail attachments
Update to Thunderbird 52 breaks Enigmail decryption of e-mail attachments
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Firefox
Leap 42.2
x86-64 openSUSE 42.2
: P5 - None : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-05-17 10:30 UTC by Sebastian Ernst
Modified: 2017-07-07 10:55 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Ernst 2017-05-17 10:30:03 UTC
openSUSE's recent update of Thunderbird to 52.1.0 breaks Enigmail's ability to decrypt & save encrypted attachments. This is a real show stopper if you use encrypted emails on a daily basis. 

Steps to reproduce: Receive an email with encrypted body and encrypted attachments. Open the e-mail in Thunderbird, type in your GPG key phrase, read the decrypted e-mail and save the attached file to disk. 

Expected result: High CPU-load (due to decryption) for a few seconds and eventually the attached file somewhere in one's file system. 

Actual result: High CPU-load (as expected) and a file of zero bytes size somewhere in one's file system. 

Likely explanation: The openSUSE-update of Thunderbird was not accompanied by an update of Enigmail. Usually, both Thunderbird and Enigmail receive updates around the same time. Right now, openSUSE ships Enigmail 1.9.5(-1.4), which explicitly only supports Thunderbird up to version number 51. Enigmail 1.9.6(.1) is available, which is compatible with Thunderbird 52. 

Workaround: Downgrade Thunderbird to 45.8.0(-39.1).
Comment 1 Sebastian Ernst 2017-05-17 10:49:55 UTC
I just tested Thunderbird and Enigmail packages from http://download.opensuse.org/update/leap/42.2-test/x86_64/: Thunderbird 52.1.1(-41.6.1) & Enigmail 1.9.7(-2.3.1). The problem remains.
Comment 2 Andreas Stieger 2017-05-17 18:26:28 UTC
Also see bug 1039471.

This works for me with all versions, including the released updates and the update in the maintenance queue. So there must be something else behind this, or another factor we do not currently see. Wolfgang, any thoughts?
Comment 3 Wolfgang Rosenauer 2017-05-17 19:32:47 UTC
It also works for me on two 42.2 systems. One is running Gnome and the other Xfce. Both seem to run gnome-keyring. Actually I have seen reports that on 42.1 gnome-keyring causes issues but I cannot confirm finally and 42.1 should be updated to 42.2 in any case.
So which desktop is it and are there any agents involved (gpg-agent, gnome-keyring, ...)?
Comment 4 Sebastian Ernst 2017-05-17 20:18:45 UTC
I am running KDE combined with whatever the defaults are if you install Leap 42.2 from scratch with KDE, Thunderbird and Enigmail. 

(The important part is that I can in fact decrypt incoming email and encrypt outgoing stuff. It's only the attachments. The CPU load, as described, really suggests that they are in fact being decrypted, too, but not written into their target files.)

Any suggestions on how to bisect this behavior?
Comment 5 Wolfgang Rosenauer 2017-05-17 21:36:30 UTC
Just to rule one thing out.
Can you please remove temporarily the package mozilla-kde4-integration or kmozillahelper (if one of it is installed) and check again?
Comment 6 Sebastian Ernst 2017-05-18 09:52:43 UTC
My initial working configuration, which works:

ernst@e7:~> rpm -qa | grep -i thunder
MozillaThunderbird-translations-common-45.8.0-39.1.x86_64
MozillaThunderbird-45.8.0-39.1.x86_64
ernst@e7:~> rpm -qa | grep -i enigmail
enigmail-1.9.5-1.4.x86_64
ernst@e7:~> rpm -qa | grep -i kmozilla
ernst@e7:~> rpm -qa | grep -i mozilla-kde
mozilla-kde4-integration-0.6.4-8.3.x86_64

First test, regular update of Thunderbird (not from the maintenance queue) - saving encrypted attachments to disk is broken:

ernst@e7:~> rpm -qa | grep -i thunder
MozillaThunderbird-52.1.0-41.3.1.x86_64
MozillaThunderbird-translations-common-52.1.0-41.3.1.x86_64

Second test, having removed mozilla-kde4-integration, it's still broken:

ernst@e7:~> rpm -qa | grep -i mozilla-kde
ernst@e7:~>

Third test, Thunderbird and Enigmail from the maintenance queue, mozilla-kde4-integration removed, and it's still broken:

ernst@e7:~> rpm -qa | grep -i thunder
MozillaThunderbird-52.1.1-41.6.1.x86_64
MozillaThunderbird-translations-common-52.1.1-41.6.1.x86_64
ernst@e7:~> rpm -qa | grep -i enigmail
enigmail-1.9.7-2.3.1.x86_64
ernst@e7:~> rpm -qa | grep -i mozilla-kde
ernst@e7:~> 

Reverting everything back to the initial configuration, and it works as expected. It's not the KDE integration, as far as I can see.
Comment 7 Andreas Stieger 2017-07-05 07:36:05 UTC
Please check:
MozillaThunderbird-52.2.1 (update repository)
enigmail 1.9.7 (update repository)
also enigmail 1.9.8 (mozilla:Factory repository)
Comment 8 Sebastian Ernst 2017-07-07 10:34:19 UTC
Ok, I just pulled in the latest updates from the regular update channel on one of my machines, resulting in the following package versions: 

ernst@linux-eh50:~> rpm -qa | grep -i thunder
MozillaThunderbird-52.2.1-41.12.1.x86_64
MozillaThunderbird-translations-common-52.2.1-41.12.1.x86_64
ernst@linux-eh50:~> rpm -qa | grep -i enigmail
enigmail-1.9.8-2.6.1.x86_64

Things are back to normal and work as expected. 

I can also test the factory version, if you'd like. From which repository should I take it?
Comment 9 Sebastian Ernst 2017-07-07 10:49:26 UTC
... and I also just pulled in all regular updates on the machine, which produced the original error. Package versions are identical. 

Things are back to normal, too, except for an odd alert - Thunderbird warned me while opening a particularly large encrypted pdf attachment (about 7 MByte) that the attachment appears to be empty. But only a fraction of a second later, I could not even click on OK in the alert, Okular opened up and presented the file to me just like expected. I have never encrypted / opened this file on this particular machine, I am sure, so I'd say it is unlikely that it was hanging around somewhere in tmp. 

Ignoring this hiccup, it works.
Comment 10 Andreas Stieger 2017-07-07 10:55:16 UTC
thanks for verifying. Closing as resolved.