From 82a14a27c9cf43ce7137e583330c412d90a1eb9a Mon Sep 17 00:00:00 2001 From: =?utf8?q?Adeodato=20Sim=C3=B3?= Date: Thu, 23 Jul 2009 19:19:51 +0200 Subject: [PATCH] fix parsing of encrypted messages that contain further multipart elements --- lib/sup/crypto.rb | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/lib/sup/crypto.rb b/lib/sup/crypto.rb index 772b8b6..64429a3 100644 --- a/lib/sup/crypto.rb +++ b/lib/sup/crypto.rb @@ -128,8 +128,26 @@ class CryptoManager end end + # This is gross. This decrypted payload could very well be a multipart + # element itself, as opposed to a simple payload. For example, a + # multipart/signed element, like those generated by Mutt when encrypting + # and signing a message (instead of just clearsigning the body). + # Supposedly, decrypted_payload being a multipart element ought to work + # out nicely because Message::multipart_encrypted_to_chunks() runs the + # decrypted message through message_to_chunks() again to get any + # children. However, it does not work as intended because these inner + # payloads need not carry a MIME-Version header, yet they are fed to + # RMail as a top-level message, for which the MIME-Version header is + # required. This causes for the part not to be detected as multipart, + # hence being shown as an attachment. If we detect this is happening, + # we force the decrypted payload to be interpreted as MIME. + msg = RMail::Parser.read(decrypted_payload) + if msg.header.content_type =~ %r{^multipart/} and not msg.multipart? + decrypted_payload = "MIME-Version: 1.0\n" + decrypted_payload + msg = RMail::Parser.read(decrypted_payload) + end notice = Chunk::CryptoNotice.new :valid, "This message has been decrypted for display" - [notice, sig, RMail::Parser.read(decrypted_payload)] + [notice, sig, msg] else Chunk::CryptoNotice.new :invalid, "This message could not be decrypted", output.split("\n") end -- 2.45.2