1693332 - want to decrypt OpenPGP e-mails to a folder

Status: RESOLVED FIXED

(MailNews Core :: Security: OpenPGP, enhancement)

Description

[Vicent]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

I tried to decrypt an e-mail to a specific folder in order to send it in plain text

Actual results:

Since enigmail has become "unnecessary" for newer versions of thunderbird, it is no longer possible to decrypt a specific email when using GnuPG instead of TB's own encryption tool.

I have configured thunderbird according to this section of the Wiki
https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards

Expected results:

As was possible with Enigmail, a menu option should be displayed to decrypt the mail into a folder.

Comment 1

[Zoe Martin]

We restored the UI and included latest Enigmail changes (motivated by the pEp implementation after bug 1680795) from
https://gitlab.com/enigmail/enigmail/-/commit/f990a63246676820c54d3e4effb8fb8961c54416
https://github.com/Betterbird/thunderbird-patches/blob/main/91/bugs/1693332-decrypt-to-folder.patch

Comment 2

[Kai Engert (:KaiE:)]

We'd like to fix this bug.
I think we should offer both "created a decrypted copy" and "move and decrypt".

We had a look at the patch from the forked project. We think it can be used as a starting point for fixing this bug.

Magnus noted that the move/delete operation probably doesn't work yet, and he is right.

Comment 3

[Kai Engert (:KaiE:)]

The current implementation allows to process multiple selected messages.

In a first test, if both an encrypted message and a plain message are selected, only the encrypted messages were copied.

How should we implement the operation?

Should we copy/move all selected messages, including unencrypted messages?
What about messages that cannot be decrypted (missing key, insecure encryption, corrupted message)?

We could also discuss whether the menu item should always be enabled/visible.

If a single message is selected, then it's easy to show or hide the menu item based on the encrypted status of the message.
However, if multiple messages are selected, that would be too difficult/expensive to examine.

For multiple messages, I'd always show/enable the menu item.
We could offer the user a choice, to decide what should be done.
The choice could be shown after the user has clicked the destination folder.
The prompt could say "Should the operation to move/copy messages include those messages that are not encrypted, or that cannot be decrypted? (a) copy/move all messages (b) copy/move only messages that are encrypted and that can be decrypted"

Comment 4

[Magnus Melin [:mkmelin]]

Good questions. I think perhaps it's better to save the "move and decrypt" to the filter action (since the move part = delete, is just a button away after copy succeeded).

I would model it according to the similar items we have:
Copy As Decrypted To > [folderlist flyout]

For multi-selection, seems we should still copy even if some are not encrypted. It would seem the goal is to have an email that can be read by anyone - so that goal is the fulfilled. Say, you have a full folder of messages (some encrypted) that you need to hand over to someone else...

For single selection, please just hide the menu if not encrypted.

In case we cannot decrypt, we should just tell the user that at the end of the operation: "4 of the messages could not be decrypted." - in case that happens. But if there are no problems, we should not prompt.

For insecure encryption and such, I would just do the decryption by any means possible. The resulting message is still insecure in all situation and there are no guarantees about it anymore. Give the user something readable, that's what they asked for.

Comment 5

[Kai Engert (:KaiE:)]

Magnus, I agree with most of what you said, but there is one complication.
We don't have code to permanently decrypt S/MIME messages.

We probably should be consistent and implement permanent decrypt for both S/MIME and OpenPGP (both for manual and for filtering).

Note that implementing a "Decrypt OpenPGP messages" could be easily done without touching S/MIME code.
I will have to check how much work permanent S/MIME decryption is.

Comment 6

[Kai Engert (:KaiE:)]

The existing interfaces to process S/MIME messages aren't fully scriptable. nsICMSDecoder uses a C/C++ callback type.

I think we need to introduce a new interface (IDL), implemented in C++, that allows passing a full message, and which will return the decrypted S/MIME message. Hopefully the amount of new C++ code will be relatively small, calling the existing implementation of nsICMSDecoder, but might have to copy some of the code from mimecryp.cpp and mimecms.cpp

Comment 7

[Kai Engert (:KaiE:)]

Attachment: Bug 1693332 - Implement permanent message decryption and unencrypted copying to a folder. r=mkmelin

Loosely based on
https://github.com/Betterbird/thunderbird-patches/blob/main/91/bugs/1693332-decrypt-to-folder.patch

Comment 8

[Kai Engert (:KaiE:)]

The base patch breaks Exchange message repairing (tests fail).

Comment 9

[Kai Engert (:KaiE:)]

Attachment: Bug 1693332 - Add tests for permanent message decryption. r=mkmelin

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/4dbfe690171b
Implement permanent message decryption and unencrypted copying to a folder. r=mkmelin
https://hg.mozilla.org/comm-central/rev/ef3c9fd0bc35
Add tests for permanent message decryption. r=mkmelin

Comment 11

[Kai Engert (:KaiE:)]

Comment on attachment 9243827 [details]
Bug 1693332 - Implement permanent message decryption and unencrypted copying to a folder. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #): no
User impact if declined: missing feature from enigmail
Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky): low, new feature

Comment 12

[Rob Lemley [:rjl]]

Comment on attachment 9243827 [details]
Bug 1693332 - Implement permanent message decryption and unencrypted copying to a folder. r=mkmelin

Comm-central to beta merge is today, so there is no need to uplift to beta.