Regarding the past EFAIL security issue, one of the remedies was to limit processing of encrypted messages to the top level of a MIME message.
Apparently this wasn't applied to messages that are a mix of MIME and inline PGP. In the provided sample, there are three MIME parts. One of them contains an inline PGP message, and our current code is willing to process it.
I think it is OK if we continue to allow processing of exactly one inline PGP message, even if it is contained in the second level of a MIME message. However, if we do, we should give it the "partial PGP" treatment. We should show the notification that it's partial. We shouldn't process it automatically, but require the user to click the button to process the partial content. And after the user clicks, we should hide all other MIME parts. (This is what we currently do for a single-part plain text message, which contains an PGP block.)
There is some existing code (which refers to a bug 983), which has this comment:
// for safety reasons, we replace the complete visible message with
// the decrypted or signed part (bug 983)
But that code doesn't work. For the given example, additional rendered content is kept.
Also, currently the code will always replace the first rendered MIME part with the decrypted/decoded contents - even if that isn't the PGP block.
We should change the code to walk the DOM and remove all unrelated DIV nodes.
Also, there is code that recursively processes the full MIME tree, and will decode any parts at any nesting level. We should remove that code for at least two reasons. (1) Our new code (post Enigmail) will use the result of decoding to update the top level message status and show status indicators, and we don't support displaying status for sub content. (2) Because of the risks described around the EFAIL security issues, we shoudn't automatically process sub content.
While testing, I discovered that for messages that we cannot process (cannot decrypt, e.g. because of a broken digest part), we will not show any OpenPGP failure status (because RNP doesn't give us an helpful error code). I suggest two changes here. (3) If we don't get helpful failure information, let's check if the message we're trying to process is an encrypted message or a signed message (according to its BEGIN PGP header), and show the respective general OpenPGP error status. (4) If we're processing partial contents, let's always reduce the shown contents. In other words, remove the code around it, and keep the PGP message that we cannot process. I've suggested this also in bug 1702582.