]> git.cworth.org Git - sup/commitdiff
fix parsing of encrypted messages that contain further multipart elements
authorAdeodato Simó <dato@net.com.org.es>
Thu, 23 Jul 2009 17:19:51 +0000 (19:19 +0200)
committerCarl Worth <cworth@cworth.org>
Thu, 17 Sep 2009 16:31:11 +0000 (09:31 -0700)
lib/sup/crypto.rb

index 772b8b696c4f4f41682fe2e51f4656bc66603254..64429a30b2562b13e7f796f55e0ff057a74ceb6f 100644 (file)
@@ -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