[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Thunderbird 78 Deprecates Enigmail

Not great. Now that the torbirdy replacement issue was finally solved… (torbirdy deprecated - replacement required) Back to a bit of chaos. Not looking forward to.

These new keys probably needs a separate backup since Thunderbird introduces its own keystore. Perhaps for users of gpg command line it would be best to create the key outside of Thunderbird and then import into Thunderbird. That way one does not have two keys - gpg and Thunderbird. In theory.

Thunderbird will probably stop being compatible with Qubes Split GPG at least until/if someone fixes that, if possible.

Quote https://wiki.mozilla.org/Thunderbird:OpenPGP:2020

Thunderbird is unable to bundle GnuPG software, because of incompatible licenses (MPL version 2.0 vs. GPL version 3+).

Great, licensing is responsible for this mess.

Instead of relying on users to obtain and install external software like GnuPG or GPG4Win, we intend to identify and use an alternative, compatible library and distribute it as part of Thunderbird on all supported platforms.

Well, the issue wasn’t Linux distributions where GnuPG is usually installed by default.


Will require updated documentation.

If it wasn’t for the updated torbirdy implementation which we rely on for Whonix (torbirdy deprecated - replacement required), I’d consider swapping e-mail clients. In theory, for Kicksecure an e-mail client with functional gpg integration that can use system gpg could be considered.

I guess the same was torbirdy deprecated - replacement required is currently doing it using folder https://gitlab.com/whonix/anon-apps-config/-/tree/master/etc/thunderbird will still work.

Attack surface? Perhaps similar. I don’t see how locally installed gpg would cause any more attack surface than Thunderbird integrated gpg. Not even a theoretic argument can be made until someone compares the code bases.

Might be better for those who only use Thunderbird and don’t mind to have the keys on the same machine (VM) as the signing keys. (No qubes-split-gpg.) But I am sure this will also add confusion as it uses a keystore separate from gpg command line.

https://www.whonix.org/wiki/E-Mail#Pretty_Easy_Privacy

Either new, separate keys. That I suppose will always be easy.
And also they mention many times the ability to import existing keys.

As for locally installed, command line gpg. Not much. Key import from gpg format to Thunderbird own format. That’s the most. No other interaction with command line gpg.

It might be wise to wait and see any bugs being ironed out?

That is a good question. I doubt there is much choice for distributions. Unless someone forks Thunderbird, restores the old functionality, which is probably unlikely, I guess everyone has to switch client or go with these changes. A small hope is that support for locally installed gpg is added.

Let’s hope that this change at least doesn’t happen before the upgrade from Debian buster to Debian bullseye. Usually Debian stable doesn’t do major version upgrades in the stable release of Debian. But is firefox-esr package in Debian an exception? By extension, is the thunderbird package also an exception? I didn’t monitor firefox version from firefox-esr closely enough but I think there might be an exception. Which would then mean this change could hit us already during the Debian buster based Whonix 15 release series.

1 Like

For the record (because I’ve not seen this mentioned before–apologies if this has been posted elsewhere):
I just updated from Thunderbird 68.12.0 to 78.2.2 on a test system (stand-alone installation) since the latter version is made available through Mozilla’s own “release” update channel starting today. Somewhat unexpectedly, I found that it’s impossible to use (i.e. (re-)import) so-called “laptop keys” (aka disposable subkeys with an offline master key).
This effectively rules out production use for me–unless a GPG-compatible backend will be provided soon/by when the old 68.x version of Thunderbird will not receive security fixes anymore addressing newly discovered flaws, it’s time to switch to another application on the desktop, I guess…

2 Likes

I am not against moving to another client that is fully GPG compatible. Do you have any suggestions/ideas you’ve tested?

1 Like

Personally, I started to look at lists like https:​//​www​.​openpgp​.​org/software/ yesterday to get some ideas. I always kept Mutt around, but as it’s text-based (even though you can bind a key to open a graphical browser to display HTML emails), it might be a hard sell for many users.

2 Likes

If you have a vote to spare and/or like to monitor this–here’s the associated bug report:

Edit by Patrick: fixed link

2 Likes

Thanks for keeping onto this. I tested 4 different clients in Debian repos today and they all fell short for different reasons.

  • Sylpheed - Sends messages fine but cannot pull them from server (imap broken)

  • Claws - wouldn’t encrypt messages - wants a security system selected, but doesn’t show GPG as an option despite installing the required plugin.

  • Geary - UI too sparse and it turns out GPG support isn’t done yet.

  • Evolution - very heavy, but the closest TB alternative. Cannot use a key with an email ID different than the one that is signed in. This is a problem for people who migrated email addresses. (Tested that you cannot encrypt an email to yourself using an old key).


Reposted your link as it doesn’t click for some reason:

2 Likes

Thanks for keeping onto this. I tested 4 different clients in Debian
repos today and they all fell short for different reasons.

  • Sylpheed - Sends messages fine but cannot pull them from server
    (imap broken)

  • Claws - wouldn’t encrypt messages - wants a security system
    selected, but doesn’t show GPG as an option despite installing the
    required plugin.

  • Geary - UI too sparse and it turns out GPG support isn’t done yet.

  • Evolution - very heavy, but the closest TB alternative. Cannot use
    a key with an email ID different than the one that is signed in.

Even if the email address was added to the GPG key?

This is a problem for people who migrated email addresses. (Tested
that you cannot encrypt an email to yourself using an old key).

What would be the use case for doing such a thing? Could you elaborate
on that?

Is there a straight forward way for doing that? The gpa interface doesn’t let you edit that. The command line gpg option wasn’t intuitive either. Needs to be documented.

Just using the same key on another inbox. Editing the key to add this address would address this.

1 Like

You need to add an additional user id for this using ‘adduid’, see

edit by Patrick:
made real link and promoted user account to be able to post links

1 Like

Is there a straight forward way for doing that? The gpa interface
doesn’t let you edit that. The command line gpg option wasn’t
intuitive either. Needs to be documented.

I haven’t done that via CLI yet, but via Enigmail, and since the
Thunderbird debacle I use Evolution, and hence Seahorse to manage my
keys. The steps via Seahorse (Passwords and Keys) are:

  1. Open it.
  2. Select the desired key.
  3. In the dialog then select “Names and Signatures”
  4. Select “+Add Name”
  5. Fill in the dialogue form.
  6. Click OK.

That should do the trick.

1 Like

Great(?) news – it looks like so-called “laptop keys” / offline master keys can still be used, so regarding this isolated issue, it might not be necessary to shop for another email client!

Short summary: After my original bug report #1666124 [1] – which I attributed, but couldn’t assign an “S2” severity (“no existing workaround”) – has been closed as a duplicate of bug report #1654893 [2] (classified as “enhancement” because “[Mozilla’s] bugzilla isn’t deciding based on previous Enigmail features.” [3]), some kind soul pointed out to me [4] that there indeed is a workaround which follows exactly the same steps as proposed for smartcards [5]. (Let’s hope that this remains an option in the future!)

On one hand, I’m at odds with the above comment [3] which basically must mean that supporting the full previous functionality of the old Enigmail add-on for Thunderbird v68 is not a current objective – I commented accordingly because at least I missed this position from previous announcements and would really have liked a longer warning time. On the other hand, I’m not sad that I don’t have to import private keys into the Thunderbird keyring at all (you still need to import the public keys, but that’s an inconvenience at most).

The wiki topic [5] also mentions the Qubes Split GPG configuration, but I currently have no working test environment at hand to verify this myself.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1666124
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1654893
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1666124#c4
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1654893#c5
[5] https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards

2 Likes

Related, connectivity issues fix:

No. Whonix doesn’t stop the upgrade. See this thread on what was actually done, not done.

Whonix doesn’t interfere with package upgrades from Debian so package security support is same Debian and for other practical reasons, Focus on low-effort maintainability, not sustainable to fork/security support Thunderbird at Whonix project level.

Unspecific to Whonix. Same as Debian. https://www.whonix.org/wiki/Free_Support_Principle applies.

It’s never a good idea to stick with old software versions because you will miss out on patches when new security vulns inevitably turn up. As long as the gpg implementation isn’t broken it is still a viable option and not something to abandon the most usable mail client over.

1 Like

i haven’t played with this too much yet. but, i’ve come across some postings that stress thunderbird can still use an external presence of gnupg in some ways. it requires some about:config style tweaks.

2 Likes

Sounds interesting. What advanced usecases does this address so we can list them? It’s worth linking to this guide on the wiki.

1 Like

it appears that it may address the qubes “split key” issue. additionally, it appears to allow for storage of keys on external encrypted drives. i haven’t tried either of those.

for me, i simply didn’t want all of my keys stored in thunderbird’s config file. while it may be convenient for people who only use gpg for sending and receiving e-mail, i still use it to encrypt and sign files that i place on servers. thus, being able to use it from the command line interface is desirable for me there. i did test this out and it works fine.

the public key management is still rather cumbersome. i don’t yet understand why thunderbird allows for the use of an external gnupg instance, but doesn’t have a similar setting to store all of the keys outside of thunderbird. so, for the moment, public keys added to the keyring in thunderbird will need to be manually exported if one wants to work with them from the command line.

2 Likes

Thanks. I went ahead and noted these advantages in a new section that you can expand on when you have time.

Would the suggested changes impact normal usage? If not, I don’t mind adding them to be enabled by default.

1 Like

It certainly would worsen usability.
Thunderbird 78 gpg key management has now worsened usability already. It uses a separate keystore. It doesn’t use gpg’s data dir. It uses Thunderbird’s data dir. Therefore a user who uses both gpg and Thunderbird has two independent key stores, gpg and Thunderbird.

The only option as far as I know is to tell Thunderbird to use gpg’s key store for private keys. For public keys this is not possible.

Therefore setting this option by default would actually increase confusion. It’s easier to know for user that key stores are now independent. The alternative that somehow private key is managed by gpg but public keys are managed by Thunderbird would be more confusing.

It does.

1 Like

i agree. still trying to think this one through. but, it may be easier to just treat external keys as a separate use case scenario. however, an upside to using external gpg is that the private key can still be password protected. but, thunderbird’s config can be password protected too. so, not sure how much of a difference there is. i’ve never bothered setting the master password for thunderbird, as i’ve simply never stored any sensitive date in the thunderbird profile.

2 Likes
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]