WARNING: Enigmail 1.7 *completely* *broken*
OpenPGP addon for Mozilla Thunderbird
Brought to you by:
pbrunschwig
Menu
▾
▴
Enigmail 1.7 is completely broken for my purposes.
Steps to reproduce the problem:
1) Write an email in TB.
2) Ensure "Force encryption" in Enigmail.
3) Ensure "Force signing" in Enigmail.
4) Recheck encryption and signing settings... OK.
5) Send the email.
6) Look at the received email. OOPS. It is NOT signed and NOT encrypted.
Sorry to say this so directly, but an encryption system, which CONFIRMS
to the user in it's graphical user interface on two different places
that it will encrypt AND THEN SENDS THE EMAIL WITHOUT ANY ENCRYPTION IN
PLAIN TEXT ... is just the BIGGEST IMAGINABLE CATASTROPHE.
Sorry for my profane language but there is simply no excuse for such
bullshit.
I am currently preparing a crypto class for journalists next week to
teach them how to use safe email.
HOW am I going to explain that? A system tells the user in a separate
window as well as in a menu line that everything will be encrypted but
then it simply FORGOT to ENCRYPT and, ooops, their report will be
intercepted and their source will be tortured ?
Ok...let's see....maybe there is some magic incompatibility with the TB
or OS version or the specific configuration I used or whatever... As a
computer scientist I can imagine many bug-explanations.
Good that I am just a computer scientist. As a serious user (dissident,
whistle-blower, diplomatic or military user) I would now be waiting for
the bad guys come and get me with their water-board.
Still as a computer scientist I need an answer to which system I will
teach in my class next week. Command-line PGP ?!?
You will need to use an older version of enigmail or recommend things like the Tails-Live system. Also othermailclients come with pgp support on board e.g. claws mail.
I understand your anger, but this is a volunteer. It seems obvous to me too that he messed up because the latest version is broken for me too. but let's cut him a little slack
Why?
The problem is, of course, not the question what I am going to do in my course.
The problem is, however, that there are many people out there using enigmail in real operative scenarios, as they are not sufficiently technically experienced to use TAILS and are happy that they have mastered enigmail. These people may have heard about a rule that it is good to upgrade your system, so their TB and enigmail is upgraded (semi)automagically. All of a sudden they end up with a system which has a new user interface and is broken in the absolutely worst way which is possible.
The program says "yes I will encrypt" and does so consistently in two different places (dialog window and menu line). However, the program sends out plaintext. This is a clear NO-NO.
Even worse:
1) The bug is known but has not been clearly communicated to those who might be affected heavily by that bug (ie. a prominent warning on all possible places).
2) The bug has been fixed in a nightly build and there is not yet a new version 1.8 fixing this bug.
3) The old, buggy version still is out there for download.
I AM STILL SPEECHLESS.
Ok. The author is a volunteer and I am happy and grateful for that and for his work. However, as HeartBleed and TrueCrypt show, volunteers are responsible for the reputation of FOSS security software...
Hi,
We have reproduced this behaviour.
It seems that the bug affects recipients in the bcc field. Enigmail seems to skip all the addresses that are entered there, and if all of your recipients are in the bcc field, the message will be sent unencrypted even though all indicators show that it would be encrypted.
If you send a message with the to- and bcc-fields populated, messages will only be encrypted with the to-fields recipient keys.
The way to avoid this is to encrypt messages manually before sending them with all the intended recipient keys or use the to- and cc-fields.
Apparently it's this bug: http://sourceforge.net/p/enigmail/bugs/294/
No, 294 is just about BCC and GnuPG's options --hidden-recipient / --throw-keyid as in http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Esoteric-Options.html
Hi,
I have this behaviour also with a single To: and no Cc:, no BCc:, albeit with probably uncommon overall configuration.
Essentially I experimented with the new configuration settings, turning off most automagic. I wanted a system where Enigmail does not bug me with questions, confirmations and reminders and only encrypts/signs when explicitly and manually instructed to do so. I then sent a testmail to my other account with a single recipient. This mail, despite requesting encryption/signature manually, was not signed.
I suppose there may be several sources for this problem.
I suggest to check the control flow of the application, as the described bug is a big issue for every seriously encrypting user who wants to be in complete manual control of what is going on.
If there is a particular settings or log file I can send to help you with this, give me a path in the file system.
Could you please post more details, like what os and version you are using? In our replication of the issue we were using bcc recipients with confirmation enabled. to and cc recipients encrypted as expected.
I am not an Enigmail developer, I work for the National Cyber Security Center Finland and we are merely trying to stay informed about this bug.
I am also able to reproduce this issue.
It is beyond belief that there has been no official acknowledgement of this problem. It is difficult to imagine a more catastrophic security failure unless Enigmail were to silently attach my secret keys to outgoing mail.
Enigmail 1.7 (20140711-1158)
Thunderbird 24.5.0
Debian Jessie
I have "Convenient encryption settings" selected in the global Enigmail Preferences. I am not sure whether this affects the issue.
From my tests, it seems the per-account "Message Composition Default Options" under "OpenPGP Security" are overriding some other settings.
If "Encrypt messages by default" and "Sign messages by default" are disabled there, then messages are sent in the clear regardless of recipient rules or the options selected in the composition window UI.
Similarly, if "Encrypt messages by default" and "Sign messages by default" are enabled, then messages are sent with encryption regardless of the options selected in the composition window UI. That is to say, manually disabling encryption/signing while writing a message has no effect.
I am not familiar with the Enigmail codebase but am happy to help diagnose the issue further.
This seems to be fixed in 1.8a1pre (20140821-0013)
The fix needs to be backported to the 1.7 branch urgently and a new version released, as this bug is present in the version of Enigmail in Debian's repo and possibly those of other OSs.
Edit: Please also see post below on nightly, please try that first!
cleca, rufo: As I'm sure you assumed, Enigmail 1.7 has undergone testing and does not show the behaviour you describe for those who tested. So yes, your help finding what's going amiss is appreciated. It might be easier for us to communicate though if you subscribe to the enigmail user mailing list. If that's OK for you, please continue reporting there (and once you can reproduce an issue in a new profile, please open a bug (after checking whether there already is one for your issue).
If you have not done so yet, please note that the "default settings" have different meanings now and that there is a "start setting" and a "overrule setting" now. Also, I suspect transition issues, that is that some 1.6 settings might not have been properly migrated and now cause side effects. If you have not done so, please create a new minimal Thunderbird profile, set up just your mail and Enigmail and reproduce your issues.
Last edit: Olav Seyfarth 2014-08-23
Edit: Please also see post below on nightly, please try that first!
cleca, Nivatius, rufo: may I ask yo to systematically gather all info in a bug?
To me it seems that it's only hitting users on Linux for example.
Also it seems that it may have to do with migrated profiles.
Prior to opening a bug, please drop a line here so that it's clear who opens it (to avoid tree bugs on the same issue). The others may then add their findings as comment.
You should make some efforts prior to submitting a bug:
- Reproduce it in a new profile. If all fine there, state it in bug.
- Enable debugging and examine the log for anything that hits your eye.
- State your system details incl. versions: OS, DesktopEnv, TB, EM, GnuPG
- State all steps to reproduce, note expected vs. actual results
I think that way we'll be able to squat it. Thanks for your help!
Last edit: Olav Seyfarth 2014-08-23
I phoned to Ludwig and Nico. Approx. 3 weeks ago there was a fix committed that may already solve your issue. Tis fix currently is only in the nightly.
If you use your distro's Enigmail, please close TB and uninstall that temporarily (it will not remove any settings). Then, install the nightly from https://www.enigmail.net/download/nightly.php and try to reproduce your issue.
Please report here whether a current nightly solves the issue so that we are sure that if we release 1.7.1, your issue will be solved even for distro version (to be released by their respective maintainers).
If not, please go ahead opening a bug as described above.
Yes, this problem is fixed for me in the nightly build, so including that patch from 3 weeks ago in 1.7.1 sounds good.
I will try to reproduce the issue with 1.7 in a clean minimal TB profile to eliminate possible migration issues from 1.6.
I was unable to reproduce the issue with 1.7 and a clean profile. So this bug may be the result of migrating from an earlier version of Enigmail.
Patrick released 1.7.2 today. Please upgrade to that version as soon as it is available for your distribution. This release should fix all security relevant issues of version 1.7 that are known to us today.
v1.7 should have been released in alpha/beta channel.
Rolling out to everybody rendering encryption completely broken was awful.
@nursoda: Sorry that I can no longer provide focused feedback here, since I have removed the 1.7 installation immediately from my machine.
I rechecked now with 1.7.2 and here the problem does not show up any more.
@buffbuff: we also realise that now
@cleca: there still are known minor issues in 1.7.2 but it should definitely no longer have security issues
I can't reproduce this at all.
Version 1.7.2 with TB 31.1.0 on Win 7/64
Instead of crying like a little baby "enigmail is so insecure" I'm gonna donate :-)
thank you guy's for doing that fussy work to get enigmail running. Just keep on going.
Thank you for your support. Money donated is used to cover infrastructure cost.
However we do acknowledge that not_encrypting_a_message is a serious issue that would better have been dealt with quicker. Development speed and appropriate reaction to security findings is not a matter of money, but caused only by a lack of time. It would be helpful to have more helping hands to fix bugs, implement user requests and do support.