GNOME Bugzilla – Bug 630295
Inline GPG encrypted message is not always recognized
Last modified: 2010-12-13 12:13:48 UTC
I received a GPG encrypted and signed message which is not decoded by Evolution. The following is displayed. -----BEGIN PGP MESSAGE----- Charset: UTF-8 Version: GnuPG v2.0.14 (MingW32) [encrypted things] -----END PGP MESSAGE----- The dialogue to enter the passphrase is not displayed. Entering my passphrase for another encrypted message does not change anything either. Saving this section to a file and decrypting it with `gpg --decrypt` works as expected. The strange thing is that another GPG encrypted and signed message from the same person is displayed correctly. I compared the message source and could not find any difference in the message header besides of course the subject, date, message id and so on. But this message is even in the same thread as the working messages. […] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: […] Subject: […] References: […] In-Reply-To: <…> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Sender: […] X-Sender: […] X-Provags-ID: […] Content-Transfer-Encoding: quoted-printable X-Evolution-Source: […] -----BEGIN PGP MESSAGE----- Charset: UTF-8 Version: GnuPG v2.0.14 (MingW32) […] -----END PGP MESSAGE----- So far this just happened with one message. I have no idea how to proceed to debug this. I appreciate any suggestion.
Thanks for a bug report. What is your exact evolution and evolution-data-server version please? I'm asking because I'm wondering whether it can be related to bug #531912, which was fixed in time for 2.30.2. With respect of debugging, maybe try to save the "bad" message to a file and then import it to On This Computer/Inbox or elsewhere under On This Computer, and check whether it'll be still non-functioning.
(In reply to comment #1) > Thanks for a bug report. What is your exact evolution and evolution-data-server > version please? I'm asking because I'm wondering whether it can be related to > bug #531912, which was fixed in time for 2.30.2. I am sorry. I am using the versions in Debian Sid/unstable [1][2]. evolution 2.30.3-2 evolution-data-server 2.30.3-2 > With respect of debugging, maybe try to save the "bad" message to a file and > then import it to On This Computer/Inbox or elsewhere under On This Computer, > and check whether it'll be still non-functioning. I saved it to mbox and imported this to Computer/Inbox. It is still malfunctioning. [1] http://packages.debian.org/sid/evolution [2] http://packages.debian.org/sid/evolution-data-server
Could you upload here the offending message for testing, please? You can remove/replace everything sensitive, like server names, email addresses from there, even the body between BEGIN and END PGP MESSAGE can be mangled, as the preview panel will claim it was unable to decrypt it anyway.
Thanks for the test message, I received it and evolution really doesn't recognize inline PGP on it for some reason. I'll investigate more soon.
Created attachment 171757 [details] [review] evo patch for evolution; This is a very nice bug. Your message exhibits a very nice thing: The EMInlineFilter properly recognized the "-----BEGIN PGP MESSAGE-----" line, but because the CamelMimeFilter parses messages in junks of 4096 bytes, and your message is 4098 bytes long (two bytes more), then the ending line for the PGP message "-----END PGP MESSAGE-----" was divided into two chunks, the beginning of it without the last two dashes, and those two dashes in the second chunk, thus the inline parser didn't recognize the ending line and behaved like when no PGP message was included in the email. Backing up the last line and continuing with it when the next chunk is received is fixing this bug.
Created commit a2b2b88 in evo master (2.91.1+) Created commit 36abdbd in evo gnome-2-32 (2.32.1+)
*** Bug 613075 has been marked as a duplicate of this bug. ***
This is #599403 in the Debian BTS [1]. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599403
*** Bug 615419 has been marked as a duplicate of this bug. ***