I was viewing an unsigned, unencrypted email. The first time I opened it, it was shown with incorrect OpenPGP security information.
The green Enigmail banner said:
"Decrypted message; Good signature from Daira Hopwood (preferred key) daira@jacaranda.org
Key ID: 0x98CF2762 / Signed on: 17/07/14 10:56"
(There was a short delay before the banner appeared, but that's not unusual.)
The result of "Copy OpenPGP Security Info" was:
"Good signature from Daira Hopwood (preferred key) daira@jacaranda.org
Key ID: 0x98CF2762 / Signed on: 17/07/14 10:56
Key fingerprint: 3D6A 08E9 1262 3E9A 00B2 1BDC 067F 4920 98CF 2762"
That is my key ID and fingerprint, but I didn't sign that message. Opening the
same message again shows an unsigned, unencrypted email with no OpenPGP banner, as expected.
The claimed signing date (17th July, i.e. the day I viewed it) is also inconsistent with the date the actual message was sent (Mon, 30 Jun 2014 19:59:09 +0000). I suspect that the signature information might have come from verifying a different email.
This implies I can no longer trust Enigmail to show me accurate signature information. :-(
I still have the message window with the incorrect banner open; I can attach a screenshot or interact with it further if needed.
This was using Enigmail version 1.6 (20131006-1849), Thunderbird 24.0, and GnuPG 1.4.14 (from the Debian package on Linux Mint Debian Edition).
Could you please uninstall Enigmail through your package manager and install Enigmail 1.7 as AddOn downloaded from enigmail.org and try to reproduce that issue?
Hi, some people have complained about this behaviour. In fact, I also suffered from this.
What seems to happen is, that some function from within Thunderbird accesses an encrypted and/or signed message in the background. This message access triggers Enigmail to do its verification and/or decryption work. Enigmail then displays the result in the window of the currently selected message, which may be a completely different one.
One of the known sources is the background indexing (aka "Global Search and Indexer"). Disabling this feature dramatically reduces the frequency of such mis-displays, but not to zero. There is some code within Enigmail not change message display if the accessed message is not the one displayed, but I am not sure if this requires Thunderbird version 31, soon to be released. I'm also not sure, if this code is already in Enigmail version 1.6 or if you need 1.7.
I'll supply this information as soon as possible.
That does sound like the same bug. The message was in a separate window, and the banner appeared only a couple of seconds after opening that window, which is consistent with it being triggered by some background processing. I do have "Global Search and Indexer" enabled (I don't remember explicitly enabling it; maybe it is enabled by default).
It may be a few days before I get around to trying Enigmail 1.7. There's no guarantee I can reproduce it in any case, since it seems to be an infrequent (for my usage patterns) race condition.
Last edit: Daira Hopwood 2014-07-21
Enigmail 1.7 and Thunderbird 31 do not help. The code to prevent such wrong display events should have worked from Enigmail 1.6 and Thunderbird 24 on. In fact, it didn't. I have caught a debug log of such an event, so that we start debugging it. In the meantime, I suggest to disable the "Global search and Indexing" to minimize the frequency of such events.
This is a crazy thing. I activated "Global search and Indexing" to trigger such occurences and got NO false display. In fact, I probably have several thousand signed or encrypted messages in all possible combinations (inline or PGP/MIME).
I have not encountered any such behaviour since Thunderbird 31.1.1 or 31.1.2.
Please, can everybody bitten by this bug test again with Thunderbird 31.1.2? Thanks!
Still happens on 31.2.0. I triggered it by sending myself an encrypted signed message while viewing a plain text e-mail from someone else. When the new message arrived, it displayed this bug. Global search and indexer are activated.
This should finally be fixed on master.