Closed Bug 1971144 Opened 6 months ago Closed 1 month ago

messenger.messages.deleteAttachments with IMAP account may cause email content deletion (when using encrypted emails)

Categories

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

Thunderbird 138
defect

Tracking

(Not tracked)

RESOLVED FIXED
147 Branch

People

(Reporter: admin, Assigned: john)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:139.0) Gecko/20100101 Firefox/139.0

Steps to reproduce:

Call made to messenger.messages.deleteAttachments method

Actual results:

The body of the email appears to have been deleted (or the email otherwise somehow corrupted).

Expected results:

Email should have been preserved.

A user of the Extract 'Em! extension reported that after using the "Permanently Detach" feature of extension (which employs messenger.messages.deleteAttachments) that the email body was no longer available -- from her standpoint, the content appears to have been deleted. deleteAttachments is the only API method used by the extension to modify emails in any fashion.

She is using an IMAP account registered with mailbox.org, and furthermore is employing encryption (the auto-PGP feature).

An issue was opened on the Github page for the extension, which may facilitate communication:

All e-mails from which the attachment was detached no longer show any contents either

For what it's worth, I happen to have an account here as well (I'm the affected user).

Right, delete/detach is not supported for encrypted emails. At the moment the add-on would need to handle that.
We have bug 297314 and bug 288700

Status: UNCONFIRMED → RESOLVED
Closed: 6 months ago
Duplicate of bug: 288700
Resolution: --- → DUPLICATE

Thanks Magnus for making me aware of this limitation. I will use this bug to make the API fail if the message is encrypted, or at least add a note to the documentation.

Status: RESOLVED → REOPENED
No longer duplicate of bug: 288700
Ever confirmed: true
Resolution: DUPLICATE → ---

FWIW, I'm heavily re-working that code in bug 1788159. Would be much easier to tackle soon.

Ok, will follow your progress and revisit this a bit later.

I set up PGP encryption against an IMAP account and sent a test message not including an attachment. What I discovered is that the message content was not encrypted in place, but rather separated into a distinct message part as an inline attachment, with headers as follows:

Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename="encrypted.asc"

A call to listAttachments returns the .asc file in the results. As this is not genuine attached content, it should be omitted. I can file a separate bug report on that if preferred.

Incidentally, when listAttachments is called against an encrypted message which includes a genuine attachment, both the actual attachment and the encrypted content file are listed.

Encrypted message including an attachment

There are multiple PGP encryption formats. Encapsulating the encrypted message (and/or signature) in an attachment is the most common one.

The function listAttachments() replaces the encrypted pgp container with its decrypted content (which can be observed by the nested mime structure), and then returns the attachments found in this on-the-fly decrypted message. The asc file type attachment is commonly used to include the users public key, and should therefore not be omitted.

To understand if you found a bug or observed expected behavior, it might be interesting to look at the return values of getFul() or getRaw() with enabled and disabled decryption.

Summary: deleteAttachments with IMAP account may cause email content deletion → deleteAttachments with IMAP account may cause email content deletion (when using encrypted emails)
Summary: deleteAttachments with IMAP account may cause email content deletion (when using encrypted emails) → messenger.messages.deleteAttachments with IMAP account may cause email content deletion (when using encrypted emails)

Dear tmccoid, in order to verify Comment #7, I would need to be able to decrypt your provided test message. As I assume that it was encrypted with your actual pgp key, could I ask you to re-create the test message with a dummy key, and provide both? Thanks!

For that, you can use e.g. alice's test key - https://searchfox.org/comm-central/source/mail/test/browser/openpgp/data/keys/alice@openpgp.example-0xf231550c4f47e38e-secret.asc (public key also in that dir)

But yes, I'm pretty sure in most cases the mail will get mangled, as the delete functionality can't handle encrypted mime properly. Bug 288700.

Attached image log.png

In Comment #7. The reporter stated:

  • a call to listAttachments returns the .asc file in the results. As this is not genuine attached content, it should be omitted.
  • Incidentally, when listAttachments is called against an encrypted message which includes a genuine attachment, both the actual attachment and the encrypted content file are listed.

I cannot confirm this with my own test case on Release or Daily. Attached is a screenshot log, working with an encrypted message, which has a small text body and a small attached image.

  • messages.listAttachments() works on the decrypted message and does not report any of the encrypted container attachments or PGP version info attachment

What version of Thunderbird was this observed with? If this can still be reproduced, please file a new bug with an encrypted example message + keys, so we can look into that.

In this bug, I will handle the broken detachment, by throwing an error for encrypted messages.

The WebExtension messages API can act on the original message, or on the decrypted
message (the decrypted message is not stored), when calling messages.getFull()
or messages.getRaw(). Functions listing attachments of a message by default act
on the decrypted message only, without an option to list attachments of the
original encrypted message (this may be added later).

Problematic is the function to delete attachments. It was assumed to also acts on
the decrypted message. This however is not supported by Thunderbird and the function
actually acts on the original message, potentially deleting the encrypted container
attachment, if the provided partName matched.

Thunderbird disables all UI entry points to delete attachments of encrypted messages.
This patch updates the API documentation and also disallows deleting attachments of
encrypted messages.

The related Thunderbird bug is tracked here:
https://bugzilla.mozilla.org/show_bug.cgi?id=288700

Assignee: nobody → john

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/28e41d535bfb
Prevent messages.deleteAttachments() to modify/destroy encrypted messages. r=mkmelin

Status: REOPENED → RESOLVED
Closed: 6 months ago1 month ago
Resolution: --- → FIXED
Target Milestone: --- → 147 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: