Closed Bug 1666073 Opened 4 months ago Closed 3 months ago

Add configuration to disable OpenPGP email subject encryption

Categories

(MailNews Core :: Security: OpenPGP, enhancement)

enhancement

Tracking

(thunderbird_esr78+ fixed, thunderbird83 fixed)

RESOLVED FIXED
84 Branch
Tracking Status
thunderbird_esr78 + fixed
thunderbird83 --- fixed

People

(Reporter: nONoNonO, Assigned: KaiE)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Please add an option (UI or hidden preference) to not encrypt the subject line, when sending an OpenPGP-encrypted message.

Use case: I often send encrypted messages to myself as a reminder for information, such as passwords, where the subject line describes the information. With all encrypted subject lines only showing ..., I have to check ever single encrypted message until I find the right one...

This is especially cumbersome on my phone or other places where I don't have Thunderbird (e.g. work/webmail) and the subject is never shown, always ... due to no integrated OpenPGP support.

See Also: → 1662408
Component: Security → Security: OpenPGP
Product: Thunderbird → MailNews Core
Duplicate of this bug: 1666178
Status: UNCONFIRMED → NEW
Ever confirmed: true

It might be ideal to have a configurable exclude-list for email addresses that shouldn't get an encrypted subject.

Duplicate of this bug: 1666437

Is there any official RFC I can refer to when explaining my (quite unhappy) non-TB receivers how to decrypt the subject? It is really quite embarrasing that I have to admit, that I can't disable the feature in Thunderbird. Is this PEP stuff?

How about this heuristics: Look for the last mail from the intended receiver, check the if the User-Agent entry in the header contains "Thunderbird" and set the subject line encryption accordingly. Is there any mail client out there apart from TB that understands the way TB encrypts subjects anyway? KMail and K9 obviously don't...

Hello,

I don't understand why Subject encryption should be enabled by default, and also without the possibility to disable it. Clients which support email encryption are already scarce, and with Subject encryption, they are even harder to use.

Right now, exchanging emails between Thunderbird 78 and:

leads to an almost unreadable mailbox at the recipients' side.
Also imagine an organization which uses e.g. roundcube+enigma, or mailvelope as their webmail client, and Thunderbird on their computers. it makes communicating with your colleagues much harder.

I would need two options:

  1. General option to enable/disable subject encryption - as I can see most users (including me) would now choose "disable".
  2. Option in message compose window to enable/disable subject encryption for an individual message - this would allow to encrypt the subject when the general option is set to "disable".
Duplicate of this bug: 1672915

As I understood the difference is only to replace the subject in the header by ... if encrypted subject ist shown.
So the simple workaround could be that the subject in the header must only be filled instead of replaced.
In my opionion it should be possible to configure the general behavior (Encrypt subject : Yes | No | As before) in the "Default settings for sending messages" section of the "End-To-End Encryption" part of each email and identity section.
As before means if the answer of an encrypted message use allready encrypted subject lines the answer should do it also. If not then the subject line should be unencrypted.

The default behavior should be overwritten in the composing window by an additional line in the Options menu and in the Security Toolbar Menu.
I'm unsure where another setting could be possible.

I think this should be refiled as a bug not an enhancement, since this is a regression of functionality and breaks many use-cases (for instance as I previously mentioned, ticketing systems like Request Tracker).

would some amount of funding help prioritize fixing this bug? if so can you share what would be needed so I could share with other affected orgs who may be interested in making sure this gets fixed? thanks!

I've started to work on this task.

Because we're looking for a solution that can be backported to the stable 78 branch, we cannot easily introduce new user interface elements for this configuration - because we want to avoid touching the user interface strings and localization.

Regarding the implementation, the following is mostly explanation for Patrick, whom I'd like to ask to review the patch.

I suggest that we continue to always use the protected header mechanisms. I think this is acceptable, even if we a plain subject header.
(Protected headers were configurable in the past with Enigmail, we dropped that in 78, and I'd like to keep that dropped.)

There was a separate account specific pref, "protectSubject", and I suggest we reuse the old setting keeping, the same name.

Assignee: nobody → kaie
Status: NEW → ASSIGNED
Summary: Add option to not encrypt headers or not encrypt subject line for OpenPGP encrypted messages → Add configuration to disable OpenPGP email subject encryption
Duplicate of this bug: 1674952

(In reply to Kai Engert (:KaiE:) from comment #12)

There was a separate account specific pref, "protectSubject", and I suggest we reuse the old setting keeping, the same name.

Yes that would certainly work for me in TB 78.

(In reply to Kai Engert (:KaiE:) from comment #12)

I suggest that we continue to always use the protected header mechanisms. I think this is acceptable, even if we a plain subject header.
(Protected headers were configurable in the past with Enigmail, we dropped that in 78, and I'd like to keep that dropped.)

Agreed, good idea. But for TB 90, we should foresee a dialog, or visible preference for this (and equally for attaching the public key)

Maybe add an configuration option.
It could be possible to add an extension which can handle this configuration for release 78 by adding a configurable button in the message window.

(In reply to Patrick Brunschwig from comment #16)

... for TB 90, we should foresee a dialog, or visible preference for this (and equally for attaching the public key)

Agreed. I'll file bugs.

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/6b9be27cb1e9
Add configuration to disable OpenPGP email subject encryption. r=PatrickBrunschwig

Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Blocks: 1675300

Comment on attachment 9185348 [details]
Bug 1666073 - Add configuration to disable OpenPGP email subject encryption. r=PatrickBrunschwig

[Approval Request Comment]
Regression caused by (bug #): no
User impact if declined: many users asked for this enhancement
Testing completed (on c-c, etc.): need test feedback, hence asking for beta approval
Risk to taking this patch (and alternatives if risky): low

Attachment #9185348 - Flags: approval-comm-beta?

In the meantime would be nice to get a patch or a short description how to completly disable subject line encryption for the moment. Possible?

Comment on attachment 9185348 [details]
Bug 1666073 - Add configuration to disable OpenPGP email subject encryption. r=PatrickBrunschwig

[Triage Comment]
Approved for beta

Attachment #9185348 - Flags: approval-comm-beta? → approval-comm-beta+
Target Milestone: --- → 84 Branch

To use this pref (in nightly, in the next beta, and hopefully eventually in a stable 78.x release), you have to manually set hidden preferences - at this time we don't have user interface for this flag.

Open preferences and find the config editor.

Filter the list by entering mail.identity.id - now the list will show you all the preferences for all your identities. This tells you which identity identifiers you have in your configuration.

Find the ID of the identity you want to change, for example by looking for the useremail preference. Let's say you find that mail.identity.id5.useremail is "alice@example.com", and that's the account for which you want to change the behavior. Then "id5" is the identifier you need.

Use a right click and use New, Boolean.

As the preference name use the following, where instead of id5, you use the the id that you found above: mail.identity.id5.protectSubject
In the next step you'll be asked to select the value. The default is true. If you're here to make this change, then the value you want is "false".

Successfully created a chat account using File > New > Chat Account from the File Menu in my test of 83.0b3 on Windows 10.

Sorry, I didn't find this in previous testing as I was using the Account Hub buttons.

I would appreciate testing feedback from volunteers who are subscribed to this bug. If you can, please download Thunderbird beta 83, make very sure you create a separate user profile (so you don't corrupt your primary work profile), and experiment with and without this flag.

I'm particularly interested if we correctly protect or not protect the subject in draft messages, depending on the configuration.

Note, giving testing feedback quickly can help us include this change earlier.

I can confirm with 83.0b3 and these instructions subject is set unencrypted!

I haven't tested in combination with split-gpg / external smartcard yet.

I found a configuration option mail.identity.default.protectSubject = true.
What is the main reason for this configuration option? Is it possible to set a default for all accounts by changing the value to false without adding mail.identity.id5.protectSubject lines?

mail.identity.default.protectSubject defines which value you get for a new account - or when there is no individual id pref set yet.

Verified with all combinations of mail.identity.id1.protectSubject unset/true/false and mail.identity.default.protectSubject true/false and in all cases subject encryption of draft messages follows the setting. This also holds for the sent messages...

What's a bit confusing is that a draft saved with protectSubject false and sent (or saved again) with protectSubject true is sent/saved with protected subject, but I guess that works as designed.

Ok, I'm using OpenPGP card on smart card reader with gnugp and with latest tb 83 beta.

It looks like the new setting is working as expected. Details will follow.

I rechecked the reading of the mails by usind TB 68 and all mails are shown as expected.
I rechecked the reading also with mutt and results are as expected. By the way mutt will never shown the encrypted subject on my system (Debian 10)

Now bonus points if you can also add a (hidden) pref for not attaching the public key when enabling encryption... Did you file a bug for that as stated in comment #18 ?

Test Details:

I made after each config change 3 mail tests:

Send a unencrypted mail
Send a encrypted mail

  1. test subject is encrypted
    without changing anything (mail.identity.default.protectSubject = true)

  2. test subject is unencrypted
    mail.identity.default.protectSubject = false

  3. test subject is unencrypted
    mail.identity.default.protectSubject = true
    mail.identity.id1.protectSubject = false

  4. test subject is unencrypted
    mail.identity.default.protectSubject = false
    mail.identity.id1.protectSubject = false

  5. test subject is encrypted
    mail.identity.default.protectSubject = false
    mail.identity.id1.protectSubject = true

  6. test subject is encrypted
    mail.identity.default.protectSubject = true
    mail.identity.id1.protectSubject = true

All results are shown as expected.

(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #33)

Now bonus points if you can also add a (hidden) pref for not attaching the public key when enabling encryption... Did you file a bug for that as stated in comment #18 ?

This is not related for this bug.
In my mails never my public key is attached. Maybe this is related to this setting found in the settings:
mail.identity.default.attachPgpKey (boolean) which is set default to false

(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #33)

Now bonus points if you can also add a (hidden) pref for not attaching the public key when enabling encryption... Did you file a bug for that as stated in comment #18 ?

bug 1654950

Hello,
I confirm I was able to run the following test with success;

changing mail.identity.default.protectSubject = false
and send an email with subject unencrypted

changing in the UI "Add my digital signature by default" as false
changing mail.identity.default.protectSubject = false
and send an email with subject unencrypted and no pubkey attached

both test works and I was able to receive email with unprotected subject

Best,
samba

(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #31)

Verified with all combinations of mail.identity.id1.protectSubject unset/true/false and mail.identity.default.protectSubject true/false and in all cases subject encryption of draft messages follows the setting. This also holds for the sent messages...

great thanks

What's a bit confusing is that a draft saved with protectSubject false and sent (or saved again) with protectSubject true is sent/saved with protected subject, but I guess that works as designed.

Currently, we always use the configuration that is found at the time of sending the message.

We currently save the configuration that was seen at the time we save a draft message (remember it as a property inside the draft). But we currently don't use that remembered property.

At some point in the future, we might introduce a control element inside the message composer, that can toggle the "encrypt subject" property for the individual message. At that point in the future, we should then start to reuse the setting that was remembered inside the draft.

Comment on attachment 9185348 [details]
Bug 1666073 - Add configuration to disable OpenPGP email subject encryption. r=PatrickBrunschwig

I'm slightly torn if we're ready to include this in the stable 78.4 yet.

On one hand side we've recently said, it might be best to give all new OpenPGP changes around 2 weeks baking time in development/beta builds, prior to uplifting into a stable branch.

On the other hand, the change here is fairly simply, we've gotten good test feedback, and it seems many users are waiting for this change.

Wayne, I'll let you decide if we pick it up now, or wait more.

[Approval Request Comment]
Regression caused by (bug #): no
User impact if declined: subject always encrypted, despite some user requiring the ability to use plaintext subjects
Testing completed (on c-c, etc.): positive feedback from several people
Risk to taking this patch (and alternatives if risky): medium, but limited to subject encryption

Attachment #9185348 - Flags: approval-comm-esr78?

Would be nice for 78 stable branch someone create a extension to add a menu icon which can switch the setting generally in a composing window.

Comment on attachment 9185348 [details]
Bug 1666073 - Add configuration to disable OpenPGP email subject encryption. r=PatrickBrunschwig

[Triage Comment]
Approved for esr78 - being behind a pref should mitigate the risks. But we should test next week's candidate specifically for this

Flags: needinfo?(wls220spring)
Flags: needinfo?(bugzilla2007)
Attachment #9185348 - Flags: approval-comm-esr78? → approval-comm-esr78+

Sorry, I don't understand what's going on here.

Flags: needinfo?(wls220spring)

I verified after release of Thunderbird 78.5.1 that encryption of subject is enabled/disabled according to the setting of the preference(s).

I checked in 78.5.1 only the following because for me it is enough that the SubjectEncryption can be changed generally for all accounts:

In my settings this setting name was allready exits:
mail.identity.default.protectSubject;true

Send a encrypted mail

  1. test subject is encrypted if nothing has to been changed
    mail.identity.default.protectSubject;true

  2. test subject is not encrypted if is set to true:
    mail.identity.default.protectSubject;false

From my point of view this issue can be closed and thanks to all who has worked on this issue.

Flags: needinfo?(bugzilla2007)

Hi,
From my point of view would be great to have an idea if a UI will be implemented for non tech-user to be able to configure not-encrypted-subject feature.

Please let's check if this is possible to implement in the Account Settings > End-To-End Encryption option page.

If it's not the place here, please point me to the right place where to discuss the UI change feature.

Best,
samba

You need to log in before you can comment on or make changes to this bug.