Closed Bug 1649030 Opened 4 months ago Closed 3 months ago

Support partial inline OpenPGP messages

Categories

(MailNews Core :: Security: OpenPGP, enhancement)

enhancement

Tracking

(thunderbird_esr78 fixed, thunderbird79 fixed)

RESOLVED FIXED
Thunderbird 80.0
Tracking Status
thunderbird_esr78 --- fixed
thunderbird79 --- fixed

People

(Reporter: KaiE, Assigned: KaiE)

References

Details

Attachments

(2 files)

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.

Assignee: nobody → kaie
Status: NEW → ASSIGNED

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

Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED

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

Important OpenPGP usability improvement for 78.x

Attachment #9162891 - Flags: approval-comm-esr78?
See Also: → 1634496

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

Attachment #9162891 - Flags: approval-comm-beta?

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.

Attachment #9163370 - Flags: review?(geoff)
Comment on attachment 9163370 [details] [diff] [review]
allow-null-in-cleanup.patch

LGTM. I'll land this in a bit.
Attachment #9163370 - Flags: review?(geoff) → review+

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 9163370 [details] [diff] [review]
allow-null-in-cleanup.patch

Prevent test failure related to OpenPGP code, satety null checks.
Attachment #9163370 - Flags: approval-comm-esr78?
Attachment #9163370 - Flags: approval-comm-beta?
Target Milestone: --- → Thunderbird 80.0
Comment on attachment 9163370 [details] [diff] [review]
allow-null-in-cleanup.patch

Approved for beta
Approved for esr78
Attachment #9163370 - Flags: approval-comm-esr78?
Attachment #9163370 - Flags: approval-comm-esr78+
Attachment #9163370 - Flags: approval-comm-beta?
Attachment #9163370 - Flags: approval-comm-beta+

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

Approved for beta
Approved for esr78

Attachment #9162891 - Flags: approval-comm-esr78?
Attachment #9162891 - Flags: approval-comm-esr78+
Attachment #9162891 - Flags: approval-comm-beta?
Attachment #9162891 - Flags: approval-comm-beta+

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.

You need to log in before you can comment on or make changes to this bug.