A correct inline OpenPGP message is one that starts the BEGIN boundary line, and ends with the END boundary line, and doesn't contain any other text in the message body.

If the message contains additional contents, before the BEGIN line, or after the END line, it's tricky to decide how to process the message correctly.

After decrypting such a message, it would be misleading to show both the decrypted contens and the non-encrypted contents. We could decide to hide the non-encrypted contents - but then we're hiding data that the user might be interested to see.

If the message is signed, it would also misleading to show both the signed and the non-signed contents. It wouldn't be obvious which parts are signed, and which aren't. Again, we could decide to hide any contents outside the OpenPGP boundary lines, but then again, we'd hide some information.

IIUC Enigmail had used the following approach: Don't decode by default, but instead, inform the user. If the user decides to process the information anyway, it would hide the extra information, process the OpenPGP part, and only show the results of processing that part.

Currently, Thunderbird will not process such messages, and displays the unprocessed message.

This patch also provides additional feedback if a message cannot be decrypted, either because of the lack of MDC, or because of the lack of the secret key.

The handling of inline should be limited to the first block.
Testing of various inline message scenarios is on the TODO list and will be handled separately.

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/4467b5c7512d
Support partial inline OpenPGP messages. r=PatrickBrunschwig

Comment on attachment 9162891 [details]
Bug 1649030 - Support partial inline OpenPGP messages. r=PatrickBrunschwig

Important OpenPGP usability improvement for 78.x

Comment on attachment 9162891 [details]
Bug 1649030 - Support partial inline OpenPGP messages. r=PatrickBrunschwig

OpenPGP - uplift request for consistency of comm-esr78, beta79 and c-c80

We get test failures
[task 2020-07-13T19:40:42.700Z] 19:40:42 INFO - TEST-UNEXPECTED-FAIL | comm/mail/test/browser/quick-filter-bar/browser_displayIssues.js | uncaught exception - TypeError: can't access property "setAttribute", document.getElementById(...) is null at messageCleanup@chrome://openpgp/content/ui/enigmailMessengerOverlay.js:394:14

I incorrectly assumed that document.getElementById always returns an element, and have removed some null checks.
Apparently null is returned in some scenarios, I guess on startup or teardown.

Let's add the null checks back.

Or I won't, because the build is currently busted.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/071aa3d66bd7
follow-up - Fix broken test. r=darktrojan

Comment on attachment 9162891 [details]
Bug 1649030 - Support partial inline OpenPGP messages. r=PatrickBrunschwig

Approved for beta
Approved for esr78

https://hg.mozilla.org/releases/comm-esr78/rev/c55bca6f963085b831aa95c42c1e69694a3c5825
https://hg.mozilla.org/releases/comm-beta/rev/546c944088de55d954f27addb771b16a01c8b45d

https://hg.mozilla.org/releases/comm-esr78/rev/cec2796eb62b29dd32273a2087f1171e14d0e4e4
https://hg.mozilla.org/releases/comm-beta/rev/234e597d5a1b43a2f9afe36b9abf18e7a93a9656

This problem remains in 78.3.1 (on OS X at least).
Can reproduce by sending from 68.12.1 with Enigmail (on Windows). If Compose with HTML and Inline PGP are both turned on, 78.3.1 will not decrypt the message.
I understand that the real problem here is the sender's settings are resulting in a message with unclear security assertions, but it does seem to be a regression given that most users will have upgraded from Thunderbird+Enigmail which did display these messages.

Just testing Thunderbird 84beta on Windows. Problem remains. Why is this bug set to "fixed, resolved"?

It's working in general. Please file a new bug if you have a case where it does not. Attach a sample email encrypted to alice to the new bug (use https://gitlab.com/openpgp-wg/openpgp-samples)