1882832 - Improve encryption detection in the MimeTreeEmitter class

Status: RESOLVED FIXED

(Thunderbird :: Add-Ons: Extensions API, task)

Description

[John Bieling (:TbSync)]

This is a performance improvement based on Kai's input to minimize the
computational work required to determine whether a message is encrypted.

Comment 1

[John Bieling (:TbSync)]

Attachment: Bug 1882832 - Process encrypted MIME parts based on headers, minimize reading MIME parts. r=kaie

Comment 2

[Kai Engert (:KaiE:)]

Attachment: msg-with-enc-openpgp-attachment.eml

This is a test message, with a plain text main part, and an OpenPGP-encrypted attachment, which can be decrypted using [e-mail]

Comment 3

[John Bieling (:TbSync)]

Kai: When we first talked about this performance improvement, one of the goals was to dynamically include attachments, if they are encrypted, and drop them otherwise (so these parts could later be decrypted and parsed). The classes this code is embedded into have changed since then, and this is currently no longer a requirement (it actually would not help). The caller defines, if attachments should be included or not.

The code which checks the body parts in endPart() (isEncryptedINLINE() and isPgpEncryptedAttachment()) needs a bit of the body data. This is achieved by introducing a threshold, keeping the first few bits of the data in deliverPartData(), if encryption detection is requested, but attachments are not requested. These partial bodies are purged in endPart() after the encryption detection code has run.

In the WebExtension API, this case occurs by calling browser.messages.getFull(<msgId>, { decrypt: false }). The returned mimeTree of an encrypted message should not include any attachments, but include decryptionStatus: skipped, to indicate that the message is encrypted (but not decrypted).

In your original proposal, you introduced this.#currentlyProcessingEncryptedPartNum to keep track of containers which may contain nested parts relevant for encryption. Since we do not need to keep these nested parts now, the flag is not needed. However, I would like to hold on to it, to keep the concept in the code, so we can use it later, if needed. I am also fine with turning it into a comment or removing it altogether.

Comment 4

[Kai Engert (:KaiE:)]

Attachment: inline-enc.eml

Another test message, again encrypted to Alice.

This time, this isn't MIME, but rather an "inline" encrypted message.

Comment 5

[John Bieling (:TbSync)]

This patch also fixed a bug which existed since at least TB78. The WebExtension code is now using this code path in TB128 and I may have a report, that this unfixed bug caused a regression for TB128. I will therefore request uplift.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/1ecd684ec903
Process encrypted MIME parts based on headers, minimize reading MIME parts. r=kaie