GNOME Bugzilla – Bug 217540
support for receiving in-line pgp
Last modified: 2013-07-24 14:39:54 UTC
There were some problems with doing it the way it was done in the 1.0 release. First off, it didn't work half the time apparently. Secondly, for encrypted blocks, we just decrypted it and treated it like text - we CANNOT DO THIS!!! We should probably pass the decrypted blurb to gnome-vfs to sniff it or something. I dunno, all I know is that you can't trust the mime type that the message says it is (unless it *could* actually be of that type? ie - if it's 7bit ascii after decrypting then it probably *is* text/*).
*** bug 215325 has been marked as a duplicate of this bug. ***
*** bug 220624 has been marked as a duplicate of this bug. ***
*** bug 218935 has been marked as a duplicate of this bug. ***
*** bug 217942 has been marked as a duplicate of this bug. ***
*** bug 220832 has been marked as a duplicate of this bug. ***
So, what's the timeline for setting PGP support straight? Evolution is great, but PGP support is crucial. I hope this is fairly high on the priority list.
*** bug 221954 has been marked as a duplicate of this bug. ***
*** bug 221933 has been marked as a duplicate of this bug. ***
*** bug 221959 has been marked as a duplicate of this bug. ***
*** bug 222100 has been marked as a duplicate of this bug. ***
*** bug 202572 has been marked as a duplicate of this bug. ***
Thomas Roessler (mutt author) has recently emailed me and a few other interested parties (?) that he's planning to drop application/pgp support altogether. He'll also only be allowing in-line pgp encryption for text/plain parts if they choose pgp_encrypt_tradition option to yes/on/whatever. also proposed was to attach parameters to parts that were in-line pgp signed or encrypted, so something like: Content-Type: text/plain; x-action="pgp-signed" or Content-Type: text/plain; x-action="pgp-encrypted" or such is his proposal. This way clients don't have to scan parts to see if they were in-line signed or encrypted, etc. Unfortunately, we can't really depend on this since mutt isn't the only client that can send in-line pgp encrypted/signed messages, so I'm not sure it'll be much of a help. We'll still have to scan, even if it doesn't have the param. This still might be useful for showing a pgp-type icon in the message-list though, if we ever decide to do that kind of thing.
*** bug 216418 has been marked as a duplicate of this bug. ***
*** bug 222603 has been marked as a duplicate of this bug. ***
*** bug 219789 has been marked as a duplicate of this bug. ***
*** bug 223174 has been marked as a duplicate of this bug. ***
Since someone asked about possibly helping with this, here are some of my thoughts on how to go about implementing this: One problem with the way we did this in Evolution 1.0.x was that some mailers (Eudora I think?) would sometimes send messages with: Content-Type: text/plain; format=flowed Unfortunately, if the format was flowed, then we either couldn't handle the pgp stuff or we would do the pgp stuff and not handle the format=flowed (I forget which way we had it, I think we handled the format=flowed but not the pgp stuff?). Also, at least the inline-pgp encrypted handler would pack the pgp encrypted block into a new mime part and mark it with an x-pgp-hack=yes parameter and pass it off to the PGP/MIME decrypt handler. This is yucky because it means the PGP/MIME code has to kludge around stuff which makes code hard to maintain. I haven't put too much thought into how to fix it yet, mostly because i've been so busy but I imagine a good way might be to write a function: mail_crypto_inline_pgp_decrypt() and mail_crypto_inline_pgp_verify() or something. These functions will somehow need to know about the handle_text_plain_flowed() handler in case the format is flowed. Scratch that, it will probably have to callback to handle_text_plain() because we may have binhex, uuencode, or more inline-pgp "stuff" in the decrypted/signed content (ie, in between the BEGIN/END PGP blah markers). This is probably the hardest part to get right. Decrypting will be mostly easy to do, you'll probably want to look at evolution/camel/camel-pgp-mime.c's camel_pgp_mime_decrypt() function to see how to decrypt pgp content. Could probably even mostly just do copy/paste. You won't want to take the decoded stream and parse it into a MIME structure though ;-) Verifying will be a little trickier. Supposedly pgp will correctly canonicalise the CRLFs but I've never trusted it so you'll notice that in camel-pgp-mime.c in the verify() function that I add a stream filter to convert to the canonical CRLF format. You may not need this, but it probably doesn't hurt. Here's where you've got to decide whether or not to re-quoted-printable encode the content (assuming the mime part was qp-encoded to start with) because there's no way to tell if the mailer qp encoded before or after signing the text :-\ Oh, and don't forget: YOU CANNOT ASSUME THAT DECRYPTED CONTENT WILL BE text/plain or whatever the Content-Type of the original MIME part was. You will probably need to sniff it with GnomeVFS or something. If it's non-text, then I don't know what you should do. I guess fake a MIME Multipart with a subpart for each block of text surrounding the encrypted block(s) and a subpart with the appropriate content-type containing the decrypted content? *sigh* that sounds like a total PITA.
scratch the mail-crypto.c idea, probably easier to just write: handle_text_plain_inline_pgp_signed() and handle_text_plain_inline_pgp_encrypted() you'll need to check for the text_specials *before* the format=flowed check. and you'll probably want the inline_pgp functions to handle outputting stuff (or else call handle_text_plain_*()) This'll mean that handle_text_plain() will be a little cleaner - it can just write all of it's content in one fell swoop and not need that awful loop anymore.
*** bug 219711 has been marked as a duplicate of this bug. ***
*** bug 223853 has been marked as a duplicate of this bug. ***
*** bug 214915 has been marked as a duplicate of this bug. ***
*** bug 224006 has been marked as a duplicate of this bug. ***
Any estimate ond this, guys? I think this is more than a simple wishlist, since at least causes innconveniences: so up to at least 'Normal' This is now a mostfreq, proposing 1.2 milestone (Ah, of course, feel free to move it...)
*** bug 224114 has been marked as a duplicate of this bug. ***
*** bug 224371 has been marked as a duplicate of this bug. ***
except that Outlook doesn't actually implement inline PGP themselves anyway, the only way is for the user to purchase a 3rd party plugin written by Network Associates for Outlook. And Network Associates is no longer supporting pgp... thus, pgp is lost and gone forever :-) o/~ ding dong the witch is dead o/~
*** bug 224397 has been marked as a duplicate of this bug. ***
*** bug 224780 has been marked as a duplicate of this bug. ***
*** bug 224705 has been marked as a duplicate of this bug. ***
*** bug 225243 has been marked as a duplicate of this bug. ***
*** bug 225515 has been marked as a duplicate of this bug. ***
*** bug 225875 has been marked as a duplicate of this bug. ***
*** bug 225919 has been marked as a duplicate of this bug. ***
*** bug 226287 has been marked as a duplicate of this bug. ***
Do I understand correctly that because NAI no longer _sells_ PGP, fixing support for in-line pgp has become a non-issue? Good PGP support is extremely important to me and I am not the only one. The world is a lot bigger than just NAI and Microsoft. We're having hard enough time encouraging users to stop sending plaintext mail, they will not switch mailers just for that. Is there any hope this will get fixed someday soon?
You are encouraged to use PGP/MIME instead as that is the standard.
*** bug 226944 has been marked as a duplicate of this bug. ***
*** bug 227192 has been marked as a duplicate of this bug. ***
*** bug 228119 has been marked as a duplicate of this bug. ***
the above dup is just another reason not to do inline pgp decryption :-)
*** bug 228680 has been marked as a duplicate of this bug. ***
Will you just continue to mark all PGP bugs as duplicates of this one instead of fixing them? PGP is back in business, Mozilla email now has a nice PGP solution... and bug 220832 is a blocker, IMHO. There is a big demand for working, solid, reliable PGP/GPG support (as can be seen by the dozens of bug reports). What is the roadmap for PGP/GPG support? Should I start looking for another mailer that actually cares about this feature? Are you waiting for a solution to magically appear?
We don't plan on supporting the deprecated inline-PGP (unless someone else implements it and sends us a patch) since we support PGP/MIME. Discussion of how broken in-line pgp actually is: From: Werner Koch <wk@gnupg.org> To: gnupg-devel <gnupg-devel@gnupg.org> Subject: Re: utf8 cipher text Date: Wed, 18 Sep 2002 16:52:22 +0200 Mailer: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (i386-debian-linux-gnu) On 18 Sep 2002 08:12:51 -0500, Jacob Perkins said: > Is encrypted text supposed to be utf8? If not, what is the standard? It is not specified. Some claim that with *cleartext* signatures the text should be utf-8 but for traditional reasons it is probably Latin-1 or DOC-CP437. "cleartext" signatures are anyway deprecated in favor of PGP/MIME.
*** bug 217541 has been marked as a duplicate of this bug. ***
*** bug 230980 has been marked as a duplicate of this bug. ***
*** bug 231842 has been marked as a duplicate of this bug. ***
*** bug 232408 has been marked as a duplicate of this bug. ***
*** bug 232458 has been marked as a duplicate of this bug. ***
*** bug 235017 has been marked as a duplicate of this bug. ***
*** bug 235656 has been marked as a duplicate of this bug. ***
*** bug 236398 has been marked as a duplicate of this bug. ***
*** bug 238550 has been marked as a duplicate of this bug. ***
As a workaround, this filter works well to check PGP in-line signed messages: IF BODY contains -----BEGIN PGP SIGNED MESSAGE----- AND BODY contains -----BEGIN PGP SIGNATURE----- AND BODY contains -----END PGP SIGNATURE----- AND PIPE MESSAGE TO gpg --verify RETURNS 0 THEN DO_SOME_STUFF Where STUFF may be changing color of the message, mark it as important...
*** bug 244121 has been marked as a duplicate of this bug. ***
my last discussion of how to implement this feature unfortunately no longer applies. I have removed the 'try' code completely. I'm not even sure how to go about it now at all. Obviously anyone who implements this will still have to add code to mail/mail-format.c:handle_text_plain() to scan for pgp foo markers, but I'm not sure where to go from there. my last suggestion also had some problems, so even it had been implemented, there would have been no guarentee that it would have worked because camel does not treat mime content as opaque normally (unless it is a multipart/signed). Why not? because mime parsers shouldn't have to (does rfc2045-2049 even say SHOULD in there anywhere about this? nope.) Later, along came multipart/signed which defined a new word 'opaque' for which MIME parsers are not supposed to touch. What's so bad about 'opaque'? Well, all of a sudden there is this new restriction on a previously widely accepted specification (MIME) which is incompatable with MIME parsers written to comply with the aformentioned spec. What does this mean for inline-pgp support? Well, we've worked around it for multipart/signed (which is why PGP/MIME works so well), but any other MIME part's raw content will not be saved (think of all the extra ram we'd have to use to keep the raw content for each MIME part!). When camel parses a message into a parsed MIME tree structure (CamelMimeMessage), it simultaniously qp/base64-decodes the content as well as converting it into UTF-8 (there's a fair bit of smarts to this, seeing as how many mail clients *cough* Outlook *cough* say they are sending iso-8859-1 when they really arent) and so once you get to the mail/mail-format.c code that displays the message and decrypts PGP/MIME parts and verifies PGP/MIME signed parts, etc - it is impossible for us to get the *original* non-decoded, non-UTF-8 converted "----- BEGIN PGP ... ----" block. This means that we can't reliably verify inline-pgp signatures (hence one of the reasons we removed it for 1.2.x, the other reason being the code was unmaintainable). Just when you were thinking it couldn't get any worse, it does: Content-Type: text/plain; format=flowed have fun dealing with that as well as multiple inline-pgp signed/encrypted blocks, plus some uuencoded blocks and maybe a binhex encoded block just for good measure. and now, when you decrypt an inline-pgp encrypted block and find that it really is text, now you have to treat this decrypted block of text just like you've been treating the outer text. because this decrypted block of text can also contain uuencoded blocks, binhex blocks, more pgp foo, etc. Oh, and don't forget format=flowed formatting if the parent MIME part has this flag. and that's assuming we knew for sure that the decrypted block was text/plain, and not image/jpeg or video/mpeg or god knows what else. if the decrypted block is image/jpeg or something, you'd need to make a fake MIME part with the data and call the appropriate display handler for that.
oh yea, and this should probably also be handled for text/enriched and text/rtf and text/html as well.
er, text/richtext rather, not text/rtf
Thought I'd throw in a comment here which, while being inflammatory, is also true: Kmail handles inline PGP perfectly. This isn't said just to be inflammatory, but more to point out that there are other linux-based GUI mailers that have managed to traverse the inherent difficulties of PGP-inline and find a solution. My *only* complaint with Evolution is its PGP support. Regardless of the "standard", almost every client that uses PGP sends its mail PGP-inline. Meaning that using Evolution becomes ridiculous when you get 20 PGP-encrypted messages a day, and you have to save each to a file and read it with "gpg --decrypt < file".
This is a big issue for me too, and I have to agree that it's a big defficiency of evolution that it can't handle inline PGP. Though I also agree that more mailers should suppoer PGP/MIME properly.
I need PGP/inline for CERT (www.cert.org) messages XEmacs mail Mozilla Enigmail (standard support) This feature is a MUST.
I am moving from KMail and would also really appreciate this feature. Perhaps the KMail source code could be reviewed or the developer questioned to see how they did it?
*** bug 258089 has been marked as a duplicate of this bug. ***
the way kmail does it is completely irrelevant to Evolution unless their architecture is like ours, which I can pretty much guarentee it's not.
I think a nice trick to workaround that problem is to pipe the e-mail message to gpg. You can do that w/ filters. I made a rule like, every incoming mail is piped to 'gpg --verify' and then if it returns 0, it's a good signature, if it return 1 it's bad signature, and if it's 2, there's no signature at all. A possible way to emphasize the signed message, I use changing color to green for good signed, and grey for bad signed. Just wondering why evo does not pipe every mail through gpg. Or at least make it possible to add 'trusted' tag into the incoming e-mails so that this kind of filters work more efficiently.
we're not going to pipe every mail to gpg. that's just sillyness.
I have another issue related to this one. evolution version 1.4.6 (debian unstable package) scenario: I have 2 different private keys, both associated with different amil accounts. Account #1 (default account) and Account #2 If I send a signed email from Account #1 to myself, the siganture verifies OK, However if i send a signed email to myself from Account #2 then the signature is reported to be bad. If I change my default account to Account #2 then the behaviour is reversed, with the email from the non default account always being reported bad.
It still (Evolution 1.5.92) doesn't works with KMail signed letters.
Created attachment 44182 [details] [review] Testcase
Ok. While I appreciate Ximian and Evolution and all you guys have done (I've used gnome since Linuxworld NYC in 2000 when I met Miguel at a party), this is rediculous. There are plenty of mailers that are not only capable of reading inline gpg messages, but it is their default method. Kmail and Thunderbird are the two that I can think of off the top of my head. I'm sure there's plenty more. They have figured out a way to deal with this, even if it is just "mostly working". Why not Evolution? According to the above posts, it is because you have to (potentially) decrypt the message, then figure out whats inside and deal with it exactly as you just deal with the message proper. Um....where's the problem? Ever hear of a recursive function? It doesn't even have to recurse. You can just pass the text of the decrypted (or signed) message to your MIME handling function (thus calling it twice) to figure out how to render it. If you wanna make it really ugly, have it show the decrypted/verified portion as attachments. It doesn't particularly matter. The point is, you are being (and yes I realize that you folks are volunteers) lazy and stubborn. There's very sane and reasonably easy ways to get around this *VERY* real problem. As much as we'd all love to have people using the MIME standard, its not realistic. There ARE MUAs that send pgp/gpg inline and we have to deal with them. I, for one, am not willing to copy and paste every Debian-Security mail just to verify the signature on it. That is a waste of my time. For the record, I have now stopped using Evolution for the first time since you folks released the first version of the Ximian Desktop. I'm quite sad really, but when you tell your users that their problem is petty, stupid, and not worth fixing, its time to reconsider who's software you use.
I read somewhere that Ximian/Novell recommends saving inline PGP messages to a file and running gpg to decrypt and verify them. Why can't Evolution automate this process to auto decrypt and verify inline PGP messages?
This really seems like it should have been fixed long ago. The general concensus from everything I've read is that inline PGP is incompatible with MIME, so this whole debate of sniffing the content, etc, is pointless. If someone wants to encrypt a MIME message (mail with attachments) then they should be using PGP/MIME. End of story. This greatly simplifies the problem; now we just need to figure out whether a message is plain text, inline PGP, or MIME. That should be trivial.
there is currently work on this, i guess this will probably go into version 2.4.
I have prepared a patch that addresses this problem and provides support for inline-pgp email. It has been reviewed several times by Michael Zucchi and also by Jeffrey Steadfast. The latest version incorporating their comments can be found at http://galactus.ximian.com/pipermail/evolution-hackers/2005-June/005899.html As described in that mail, there is one small problem with the patches at the moment which has prevented me from sending them to evolution-patches yet. However I'm using them daily and they work great. Testing would be much appreciated.
Created attachment 48267 [details] [review] Inline PGP processing support in the backend
Created attachment 48268 [details] [review] Inline PGP display support in the mailer
Created attachment 48269 [details] [review] Format changes required to display inline signed/encrypted messages nicely Full functionality is present without this patch, but the display will not be as expected. This patch makes inline signed/decrypted messages display as a normal message would.
matt, since your patches went into 2.3.4, can this be closed as fixed? quoting from the 2.3.4 release notes: "Inline-pgp signature/encryption support (Matt Brown)"
I believe so. I haven't personally had a chance to build 2.3.4 yet, but the code is definitely there and I see no reason why it shouldn't work :)
marking fixed as per patch applied
uhm, if matt is still interested in coding, bug 314333 is about "Reply to an inline-PGP encrypted email does not decrypt orig email in body". :-/