1884463 - When manually entering "custom from email address" in composer window, better assist the user to ensure no other leaks are present in the message, such as attached PGP keys or digital signatures.

Status: NEW

(MailNews Core :: Security: OpenPGP, defect)

Description

[Amanita]

Steps to reproduce:

This is critical. PGP and aliases dont work well together. PGP is for verifying a users identity, aliases are for hiding it.

Actual results:

I just encountered the bug that I entered a manual email to send from, which is one of my aliases. Thunderbird sent the PGP key of my main email address, linking both together, making the alias worthless and breaching my identity

Expected results:

Thunderbird should only attach the PGP public key when the sender mail is the one of the pgp key, especially in the case where the mail was manually entered,

Comment 1

[Amanita]

this is about TB 115 Flatpak

Comment 2

[Kai Engert [:KaiE:]]

I cannot reproduce the issue using TB 128.x

I use a primary identity with an openpgp key configured, and a sub-identity that does't have one configured. I compose an email with the primary identity, I select "attach my openpgp key", then I switch to the other sub-identity and send the message. The received message doesn't contain an attached key.

Comment 3

[Kai Engert [:KaiE:]]

Ok, I can reproduce.

Now I understand which feature you're referring to.

When composing an email, when opening the drop down menu for the "from" email address, there's an entry for customizing the from address.

If manually changing the from address, the other parts of the configuration are kept. This includes the attached openpgp key.

I'm guessing this will also keep other things like the digital signature.

I agree we should find a way to make it clearer that chosing this option may leak the user's identity through secondary configured elements - or we should better assist the user, by automatically disabling all related options that may leak.

Comment 4

[Kai Engert [:KaiE:]]

I think fixing this bug would require to completely disable all signature and encryption functionality (for the given email) when a manual from address is used.

In my opinion it would be cleaner to configure a separate identity for your email account, in which no email signature/encryption capabilities are configured.

Comment 5

[Justin Tracey [:jtracey]]

Disabling signatures and key attachment makes sense to me, but why no encryption?

Comment 6

[Kai Engert [:KaiE:]]

When sending an encrypted email, we always "encrypt to self" in addition to encrypting to the recipient.

We currently don't support "encrypt to others, only", as it would be confusing if the sender isn't able to read their copy in the sent folder.

That means, encrypting to self could also leak who the real sender is.

Comment 7

[Kai Engert [:KaiE:]]

edit: fixed mistake in previous comment.

Comment 8

[Kai Engert [:KaiE:]]

How about a simpler solution. If a manual "from" was set, enable a "warning mode" for the current window, that will be remembered as long as this specific composer window remains open.

If the user has already enabled any sign/encrypted/attached-key functionality, or if the user enables it later on, display a notification bar at the bottom of the window, which warns the user about the risk of leakage.

This would probably be easier to implement, and less confusing, than automatically disabling functionality (as that would have to go together with explanation also).