Since I'm using GnuPG 2 or since I updated to Enigmail 1.8.1 (I'm not sure which it is), I'm getting conflicting messages from Enigmail for PGP/MIME encrypted messages. It doesn't seem to happen with PGP/Inline encryption.
The message is decrypted correctly (I can read the text) and the Enigmail info bar in the message is green. The text in the bar first says that the message was decrypted, but then goes on to mention an error and that the decryption failed:
Decrypted message; Error - decryption failed; click on 'Details' button for more information
The text in the Enigmail security info is as follows:
Enigmail Security Info
Decrypted message
Error - decryption failed
Public key 0D84BE856C294338 used to verify signatureGood signature from Simon May <***>
Note: The message is encrypted for the following User ID's / Keys:
0x4BC4BCC650BA88AD (Simon May <***>)
I also have a mail which is not just encrypted to myself, which shows a slightly different message in the Enigmail bar, "Decrypted message; Error - no matching private/secret key found to decrypt message; click on 'Details' button for more information", and the security info:
Enigmail Security Info
Decrypted message
Error - no matching private/secret key found to decrypt message
Public key 558AB024ED99DA66 used to verify signatureGood signature from *** <***>
Note: The message is encrypted for the following User ID's / Keys:
0x4BC4BCC650BA88AD (Simon May <***>),
0x558AB024ED99DA66 (*** <***>)
A third case is a draft I have saved. The text in the Enigmail bar is the same as in the first example, but this time, the bar is red. The security info is as follows:
Enigmail Security Info
Decrypted message
Error - decryption failedgpg: WARNING: The GNOME keyring manager hijacked the GnuPG agent.
gpg: WARNING: GnuPG will not work properly - please configure that tool to not interfere with the GnuPG system!
gpg: encrypted with 4096-bit RSA key, ID 50BA88AD, created 2013-09-12
"Simon May <***>"Note: The message is encrypted for the following User ID's / Keys:
0x4BC4BCC650BA88AD (Simon May <***>)
These emails were decrypted without any errors when I used GnuPG 1 and Enigmail 1.7.2.
Can you please supply debug log? (Instructions: https://www.enigmail.net/support/bugs.php, lowest section).
I have attached a debug log where the three examples mentioned above were decrypted. Note: I have replaced names (other than mine) and email addresses with '***'.
Thanks. The problem are these lines:
gpg: WARNING: The GNOME keyring manager hijacked the GnuPG agent.
gpg: WARNING: GnuPG will not work properly - please configure that tool to not interfere with the GnuPG system!
[GNUPG:] ERROR check_hijacking 33554509
Can you please deactivate the Gnome Keyring manager (at least for GPG activity), configure the correct pinentry and try again? Your display problem should go away.
Indeed, using gpg-agent, Enigmail does not display any errors or conflicting messages.
By the way, I just spent ages trying to disable gnome-keyring on Ubuntu 14.10 due to launchpad bug 1387303.
Still, even with the fix that has been released, disabling it is not exactly trivial, so I'm just going to leave this here:
To disable gnome-keyring for gpg with Ubuntu 14.10 (and possibly future versions), it is necessary to add the line
to either the file
or
Exactly this step has to be taken, because a startup script in
greps for this specific line in the files mentioned above and will enable gnome-keyring for gpg if it doesn't find it. I'll keep myself from complaining about how this is really obscure and annoying.
Still, I think Enigmail's behavior should be improved if gnome-keyring is used with gpg2 (see my comment below).
I'm not sure the report should be marked as invalid. Under no set of circumstances should Enigmail report contradictory messages such as "Decrypted message; Error - decryption failed". If it is decided that Enigmail does not want to support gnome-keyring, this should be stated in an error message. What should NOT happen is that inconsistent and contradictory messages should be thrown at the user because that will only cause confusion and further bug reports which could be avoided.
I fixed this in the sense that the error is currently completely ignored. I don't have an environment where I can test it though.