1911080 - Problems when trying to send an unencrypted response to an OpenPGP encrypted message

Status: VERIFIED FIXED

(MailNews Core :: Security: OpenPGP, defect, P1)

Description

[Ellie]

Attachment: Screenshot showing the error when trying to send for the first time

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

Steps to reproduce:

1. Enable AutoGPG with your e-mail provider, as in all e-mails end up getting PGP-encrypted on the IMAP server automatically.
2. Import the corresponding PGP key but make sure it doesn't match whatever Thunderbird sees as your local account e-mail, so that it won't let you use it for sending. (Which I think it should actually should let you do and which I'm stuck on here: https://bugzilla.mozilla.org/show_bug.cgi?id=1909425 but this seems like a separate issue)
3. You can now read the e-mails despite the automated PGP encryption server-side, but you won't be able to respond encrypted. This setup is important to reproduce the issue.
4. Click "Respond all" on any e-mail.
5. In the compose window, immediately uncheck the "Encrypt" button since that won't work anyway for sending, for above reasons. The "Encrypt" button will now be grayed out and show a padlock symbol with a red dash over it.
6. Type some text into your response
7. Now either click "Save" or click "Send", or wait for the automatic draft save. For any of these, you should see the errors I attached pop up, which seems like it's unintended given you just disabled encryption. Also, when repeating a failed "Send" there will just be no error anymore, with no clear explanation of what changed.

Actual results:

Explicit draft "Save" fails, first "send" fails (but subsequent ones work), any automatic draft save fails.

Expected results:

Draft saving and final send always work fine when "Encrypt" was previously disabled by the user on a per mail basis.

Comment 1

[Ellie]

Attachment: Screenshot of the error when a draft save happens

Comment 2

[forseti]

I experience the same issue, however I can't always get past the error message, even if I try it multiple times.

For example, I just had an email conversation with my boss and no matter how many times I tried it, I couldn't get past the error message. Then I tried sending some test mails to a secondary account and here I could get past the error message on my 2nd try.

Sometimes the only way to get past the error message is by removing the "encrypt" button however I'm also using the extension "send-later" and in their changelog they warn against disabling this button because of another bug: https://extended-thunder.github.io/send-later/release-notes

There is something seriously wrong here.

Version: 128.0.1esr (64-bit) - Thunderbird for Linux Mintmint-001 - 1.0

Comment 3

[Ellie]

Thanks for your input! I'm curious, how would you remove the encrypt button, or disable encryption more than it already is?

In any case just to clarify: the "Encrypt" is already disabled for me, yet I am hit with this error. I'm in fact unable to ever save any drafts with this error that the encryption somehow can't be handled, even though encryption is visibly disabled. Thankfully, after attempting sending multiple times at least on 2nd try I can send the e-mail, unencrypted as I intended.

While I would actually like to use encryption ( https://bugzilla.mozilla.org/show_bug.cgi?id=1909425 ), for now I'm not doing so since I can't.

Comment 4

[forseti]

(In reply to Ellie from comment #3)

Thanks for your input! I'm curious, how would you remove the encrypt button, or disable encryption more than it already is?

You can click on View - Toolbars - Customize and then drag the "Encrypt" button into the new window to remove it.

This seems to also remove the check that causes this issue for us.

It's pretty unusual that simply removing a button from the GUI also changes the behavior of the program.

Comment 5

[Magnus Melin [:mkmelin]]

https://searchfox.org/comm-central/rev/b99b9e5fa3b895c9a44102cf13a3bd4ac6aee956/mail/components/compose/content/MsgComposeCommands.js#5364 should probably account for gUserTouchedSendEncrypted

Comment 6

[Kai Engert [:KaiE:]]

Sorry for not looking at this earlier.

Magnus, thanks for your analysis, based on the bug description, it sounds like you found the explanation.

I will work on reproducing and testing your suggested fix today.

Comment 7

[Kai Engert [:KaiE:]]

No, something else is happening.

We have separate objects for storing the settings for a S/MIME message (which is controlled by C++ code) and a OpenPGP message (which is controlled by JavaScript code).

When we initially construct the window and data fields, we know it's a reply to an encrypted message.
We initialize both data structures with encryption turned on.

While working with the compose window, we only update the JS flags.

Later, when sending the message, if S/MIME isn't selected as the technology (the default in my scenario), we fail to update the encryption flags that will be used by the C++ code.

When we arrive in the C++ code for sending the message, it sees the initial state, which had encryption turned on. The C++ code tries to encrypt, but fails, and shows the error.

The fix will be to update the copy of the C++ flags before sending. The right place to do that is apparently GetComposeDetails().

While investigating and experimenting, I also ran into a JS exception.

Uncaught (in promise) TypeError: emailsWithMissing is null
updateKeyCertNotifications chrome://messenger/content/messengercompose/MsgComposeCommands.js:3978
continueCheckEncryptionStateSub chrome://messenger/content/messengercompose/MsgComposeCommands.js:3839
MsgComposeCommands.js:3978:7

I'd like to fix that with the same patch.

Comment 8

[Kai Engert [:KaiE:]]

And I found additional mistakes while investigating.

When working on bug 135636, I had failed to remember that we have two difference places for tracking whether a message is known as an encrypted message. Our code sometimes checks only one of the places.

Comment 9

[Kai Engert [:KaiE:]]

An easier way to reproduce is this:

• setup OpenPGP
• send an encrypted message to yourself
• change account encryption settings, de-select your OpenPGP key (select none)
• click the encrypted message you have received
• reply
• the compose window that opens has encryption enabled
• click encryption button to disable
• change the recipient address, change it to any invalid address (to ensure sending with encryption isn't possible)
• click send

You should now see a message that sending isn't possible because of encryption or signing settings.
Sending isn't possible.

Expected after the fix:
Sending the message without encryption/signing works.

Comment 10

[Kai Engert [:KaiE:]]

(In reply to Magnus Melin [:mkmelin] from comment #5)

https://searchfox.org/comm-central/rev/b99b9e5fa3b895c9a44102cf13a3bd4ac6aee956/mail/components/compose/content/MsgComposeCommands.js#5364 should probably account for gUserTouchedSendEncrypted

I think that for now, we can keep this place as is, or investigate in a separate bug.
This is executed when the user switches the from identity.
The worst is that we re-enable the encryption setting in that scenario, but the user should be able to manually disable encryption.

Comment 11

[Kai Engert [:KaiE:]]

Attachment: Bug 1911080 - Ensure C++ email compose code operates on correct composeSecure flags. r=mkmelin

Related correctness changes:

• Two variables that are always treated as an array shouldn't get initialized to null, but to an empty array.
• When deciding whether an URI refers to an encrypted message, always query both S/MIME and OpenPGP trackers.

Comment 12

[Kai Engert [:KaiE:]]

I wonder if this ever worked.
Probably not many people tried to send an unencrypted reply to an encrypted message.

Comment 13

[Kai Engert [:KaiE:]]

https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=54589a32a5295cdb903d4b0b86196f04fdf27f9c

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/60c7fa68f70b
Ensure C++ email compose code operates on correct composeSecure flags. r=mkmelin

Comment 15

[Ellie]

Probably not many people tried to send an unencrypted reply to an encrypted message.

For what it's worth, it can be a meaningful scenario when using a provider that offers automatic PGP at rest, like posteo, protonmail, etc. do. In that case, incoming mail gets immediately encrypted on the incoming(!) server no matter who it was originally from, but when you reply since most normal businesses etc. don't know how to handle PGP, you'd usually reply unencrypted again.

Comment 16

[Corey Bryant]

Kai, do we want to get this into 128?

Comment 17

[Kai Engert [:KaiE:]]

(In reply to Corey Bryant from comment #16)

Kai, do we want to get this into 128?

yes

Comment 18

[Kai Engert [:KaiE:]]

Comment on attachment 9427564 [details]
Bug 1911080 - Ensure C++ email compose code operates on correct composeSecure flags. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #): 135636
User impact if declined: replying blocked for some messages
Testing completed (on c-c, etc.): yes
Risk to taking this patch (and alternatives if risky): low

Comment 19

[Corey Bryant]

Comment on attachment 9427564 [details]
Bug 1911080 - Ensure C++ email compose code operates on correct composeSecure flags. r=mkmelin

[Triage Comment]
Approved for esr128

Comment 20

[Daniel Darnell [:dandarnell]]

Thunderbird 128.4.0esr:
https://hg.mozilla.org/releases/comm-esr128/rev/6c9a5fd8ba8d

Comment 21

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Managed to reproduce this issue with the affected build from 2024-08-01(20240801104821) using the steps from comment 9.
Confirming this issue as verified fixed with 133.0b3(20241107210012) using Windows 11, macOS 14, and Ubuntu 22.