Right, but then Thunderbird regularly prompts you to update to 78.x, and I’ve almost clicked ok several times already. I assume there’s probably a setting one can toggle in the config editor to turn off the prompt, but there should really be an option in the UI.
When this type of stuff starts happening, I take it as a sign that the software has reached "critical mass", is now in a runaway cycle of increasing abuse of its users, and migrate away as quickly as possible.
Thunderbird, years ago for me.
If a human acts abusive towards me, it is logical to end the relationship, even if it is years old.
I am a tolerant person, so once or twice I may accept excuses and justifications, but after that, it's time to distance myself.
I don't see why it should be any different from software. If I feel like I am dependent on it and "can't" move away, all the more reason to prioritize finding alternatives.
It is irrelevant whether the causes are incompetence, malice, or "accidental", the result is all the same, and I cannot allow it.
There is still, somehow, nothing I've found that's better than Thunderbird for an open source desktop GUI email client. Little choice but to allow it for many users like myself.
Worse still - even many of the proprietary ones now rely on 3rd party servers for "cloud" features, or are bloated and ugly electron apps.
There's not much in the email clients landscape; almost nothing in Linux, actually. I suppose that this is because nowadays almost all the users read email from web clients.
For me TB just works (especially because I'm locked at the ESR version, 68), however, I've never been extremly happy of it.
"I know I shouldn't stay with them, but they are a good person, and even if they beat me, I just don't know if there are any better options out there."
No offense intended, that's what your comment sounds like.
If you start looking, I bet you will find some options.
There is a variety of desktop mail clients, but the vast majority (of cross platform _and_ open source) is small-ish unkown-ish programs. The plugin system is in my opionion important (like for browsers) functionality, so popularity of a client is a significant factor, in order to have plugins available.
Evolution is possibly the only valid competitor, however, it's not cross-platform as Thunderbird.
Which version of HTML is used for email? No javascript for instance right? Possible to make a reduced parser for which it is easier to verify correctness?
For a very long time, the limit was Outlook on Windows, which used the Word 2003 parser. So, whatever was supported by Word 2003.
But, more recently, mail campaigns have instead targeted Gmail, so "whatever Gmail renders" (this is not everything a browser renders, but is close). It's not feasible to implement a subset for this and do parallel CVE fixes.
Thunderbird renders HTML using the same rendering engine as Firefox, although the email doesn't use the HTML5 doctype (so it's quirks mode), and several features are disabled (e.g., JS, frames).
There's been a couple of working groups that have attempted to standardize HTML support in email, but they don't get very far on account of having almost no representation from anyone who actually works on email clients (on account of most of the interest being email marketers who want to complain about HTML support).
The actual support for HTML is probably these days mostly HTML5 (in terms of the actual parsing algorithm), with several elements unsupported, and the CSS support being very spotty. Many MUAs are using whitelists of elements to support (don't expect <video> to make it through, and especially not <iframe>), and scrubbing CSS themselves with whitelists. In effect, this means that virtually everything added in HTML5 probably won't work, so the support is more akin to HTML4 in that regard. Infamously, Outlook uses the same HTML rendering engine as Word, which is (was?) based on the IE 5.5 rendering engine.
> Thunderbird renders untrusted HTML content and therefore is subject to a steady stream of CVEs and must stay absolutely up-to-date with Gecko
Thunderbird will prompt the user to decide whether they want to render remote content. I'm not sure if that's the default setting, but that's how it's worked for me for many years over multiple installations.
> WebExtensions are not sufficient to allow an Enigmail extension to run an installed binary
I don't know about the situation in thunderbird, but in firefox this isn't entirely true. It is possible to communicate with a native executable using a JSON protocol over IPC, if that native executable is registered using a manifest file (See https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...). so it would be possible to use a wrapper executable that communicates with the extension using native messaging, and invokes gpg as needed. However, as I understand it, the native executable would need to be installed out-of-band (meaning it isn't part of the extension bundle itself).
Instead of trying to reimplement GPG, they could have added the necessary APIs to WebExtensions.
Not directly related, but maybe Thunderbird shouldn't use Gecko to render emails. A smaller renderer with limited features may be sufficient and more secure.
That's about the bare minimum. Does any modern client not do that? But I think an HTML renderer that doesn't even have support for Javascript, audio and video tags, perhaps parts of CSS, etc. has a smaller attack surface.
this is hands down my biggest beef with most shiny new crypto libraries (and the push to reimplement all the things with them) -- almost never support for hardware key storage
It also doesn’t use GPG’s keychain. If you “upgrade” from Enigmail, it will try to import your keychain. Now you have two keychains :( Of course, if you’ve detached your primary key, the import will fail (in a very unclear way), so you have your GPG keychain and a half-baked duplicate of it in Thunderbird. Then the UI for encrypting and signing mail is hidden away in a menu somewhere, so I forget to turn it off when I don’t want it (some legacy systems don’t react well to the “weird” attachments). When I do want it, it magically knows my passphrase and encrypts/decrypts/signs automatically, whether it’s me at the helm or not. So much for security at rest.
Honestly, I was really frustrated and disappointed by the upgrade. It’s not easy to roll it back, either, apparently. I haven’t risked it, but I sorely miss TB68 with Enigmail.
Thunderbord uses openpgp.js, far from half-baked. Among others, Proton uses it.
I'm obviously not happy for users who can't use TB now, but this external GPG-client stuff has to die. It never was userfriendly, and is only safe because the target audience is so small nobody bother. Passing around secrets on stdout?
A primarily JS implementation is absolutely not as mature as the agent you were probably using before. Broadly I think I agree with you, but it would have been just as easy for TB to respect what you already had set up if that existed and use whatever they feel is right if not.
Before they used a half-baked C library that interfaces via Text-based RPC to GPG directly (which has already seen some CVEs). I'd take the gpg.js implementation over that any day.
Stdout is at least a defined tunnel through a defined process barrier with known and well-tested properties. Good luck with opengpg.js which keeps sensitive data in the same address space and JS VM as all the ad-tracking scripts you get in your spam folder. Crypto in Javascript is a huge step back in terms of separation and side-channel-avoidance (which is a big thing in RSA, like most of GPG communication).
Email doesn't run JS. That's why they have to use tracking pixels (images) and unique links.
Your first sentence was great, but the whole JS rant didn't land. I can't see how side-channels are relevant unless an attacker is already in the system, at which point they could just grab the plaintext.
"Optional security protections also include disabling loading of remote images within messages, enabling only specific media types (sanitizer), and disabling JavaScript." says the TB wikipedia page. The arch wiki says "JavaScript is disabled for message content but not for RSS news feeds. To disable set javascript.enabled to false in the #Config editor.".
So with evidence to the fact that TB does indeed execute attacker-supplied JS I would like to ask for a reference for your claim.
- The main issue is that your private key is supposed to be secret – not uploaded to a server you don't control. Of course Protonmail encrypts it, but passphrases are supposed to be an additional layer of security, not the only one. If Protonmail has a data breach, is compelled to surrender your keys or turns out to be untrustworthy, your messages are only as secure as your password.
- You cannot control when a web app is updated or verify that everyone else got the same update. So Protonmail – or an attacker that took control of their systems – could give you an update that gives them your unencrypted keys. That may be mostly a theoretical issue because few people do that with their local software either. Still, I'd trust the Debian/Ubuntu repositories more.
- Web apps have additional attack surfaces compared to local software. Malicious browser extensions can't access the data of local software, nor is local software suspectible to things like XHR attacks.
I'm not saying the implementation is half-baked (although, it does feel much less mature than Enigmail). I'm saying that the broken, imported, duplicate keychain is half-baked because it failed to import cleanly due to a lack of features. Ultimately, I had to give up on that and start from scratch with my backed up key (where the primary isn't detached).
I initially tried to fix this by messing with my GPG keychain, because my underlying assumption was that they shared keychains. Imagine my shock when I realised my assumption was wrong! Fortunately I didn't lose anything important. Either way, having to maintain separate keychains is already enough of a deal-breaker for me... Maybe it will improve over time. I guess I'll have to wait and see, as I didn't back up my TB68 profile, so I can't downgrade :(
OpenPGP.js as such is a fine implementation, one in which I have more faith in terms of security than what came before. The TB implementation is more limited than Enigmail expert mode, which I think was part of their original plan: open PGP up for wider use.
It's a small team, and this was announced I think nearly a year ago. It's a pity that apparently the import isn't without issue, but I can see how they expect expert users to be able to fix any problems they encounter.
The whole multiple keychain-thing is or was not communicated clearly anywhere ever, I've stumbled on this before. That's part of the bad design though, a keychain file would have made so much more sense and be easier to reason about than configuring it through arcane gpg incantations. I steered clear of it, but I'm surprised that Enigmail supported it (did it?).
Anyway, one 'internal' ring is a very good idea, and I'm happy TB went that way. That was a very conscious decision, as Openpgp.js development is much more active and open, so don't count on this changing.
The new UI could use some polishing (one or zero click encryption please!) but generally I am happy, and happy that I don't need Enigmail anymore.
I don't care whether TB uses gpg or its own internal implementation, that's an implementation detail. But not using the same keychain as the rest of the system is not user-friendly.
And how is stdout not secure? We're talking about pipes here, not terminals.
If you’re reading this thread, please leave a comment to say if you do or do not use PGP with email. I suspect few do.... it’s very very hard for ordinary users to grasp.
I sign every message I send. I like that I can reasonably prove exactly what I did or did not write. Can’t remember encrypting any other than the occasional test message.
I gave up on Thunderbird with the release of 78. Previously Emigmail was just functional enough once I got its finicky settings all dialed in.
Now I’ve gone all in on [MailMate](https://freron.com/) on macOS. Out of the box PGP support was only one of many pleasantries I found when I first tried this a few weeks ago. It’s dramatically changed my idea of how well a GUI MUA can actually work. Money well spent!
Signing let's you prove what you did write, it doesn't let you prove what you did not write, since all the signed emails in the world don't prove the nonexistence of unsigned emails from the same sender. Now, if you have a regular practice of signing emails, one without a valid signature that purports to be from you is pretty strong evidence that either you didn't send it or you anticipated the need for future repudiation, but it doesn't itself prove anything about which of those applies.
When I ended up casually using PGP for personal email, it was for encryption when emailing with some friends at other schools, expressly because not everyone at one site or the other was trusted not to snoop on other people's emails. Not that PGP alone would've been enough defense against a determined and knowledgeable systems person, but it did presumably offer some privacy (and also, just the principle of it).
Then I fell out of the habit, so I'm curious in what kinds of scenarios you envision in which your habitual use of email signatures would help?
No, not really. I have it set up, I attach my public key but I have yet to talk to someone who responds with an encrypted message. Then again, I'm not a heavy email user and I use other means of communication for regular contacts. If an online service (that has email functionality) supports it though (and I think more should) I'll gladly enable that.
I work for an organization that sometimes receives sensitive data. We support PGP email (among other options). It s not used that much, but I think it is important to at least offer it. "be liberal in what you accept".
I have been using Thunderbird with Enigmail since 2010 at least (if not 2008) and we encrypt all e-mails in our workgroup by PGP.
The new implementation is disastrous. I cannot read some e-mails encrypted by Symantec Encryption Desktop and UX needs some improvements too. Enigmail showed the cryptographic status of an e-mail with a conspicuous colored tab, this implementation indicates it somewhere on the edge of the screen in small letters.
I'm a very light user of the new Thunderbird + GPG signed emails. Getting the keys into it was of a novel experience, but hey there aren't many and thereafter it signs emails just fine.
Verifying received email is more problematic. There are far more of them, it can't get them from the GPG database I trust, it can't get them from a key server and manually importing them is again ... novel.
I understand the reasons for not wanting to use GPG to verify emails as they come from an untrusted source, not using it to sign emails could possibly be justified for forwarding emails from untrusted sources with attachments, not having nice way to import your trusted keys and keys from key servers I hope is only because this is version 1.
I use it. I have Facebook configured to use OpenPGP for their emails to me, so I get a steady stream of encrypted messages from that, and a couple of friends occasionally encrypt their emails to me.
In particular, institutional email is accessible to the company. I am conservative in my emails assuming that everyone sees the message. Some of us have PGP keys and feel better to gossip :)
I use it for various other tasks too (exchanging API tokens, passwords, emailing myself documents, etc ).
I do. Not exchanging exciting messages with some secret group of revolutionaries but I've been getting encrypted real time notifications of any account movements from my bank for over a decade.
And I'm a big victim to the note-taking pattern of "mail to self" and that gets a huge feature boost if you can do encrypted mail to self. I like it as my main secrets store because it's almost natural there to add a layer of mild obfuscation to your PINs and the few major passwords that get this treatment.
The article has many problems past the generally insulting tone. The most interesting one I saw on a quick scan was the implicit suggestion that anyone would be happy if their emails immediately disappeared after reading, so as to establish forward secrecy. The article doesn't bother to define exactly what is meant by email so it is hard to know exactly what they are proposing as an alternative past the bizarre mention of Signal.
Imagine HTTPS but where the site name and the URL of the resource were in plaintext and only the body was encrypted. That’s what PGP email feels like.
It’s useful for closed circuits though, where you have a group of correspondents needing to prove their authenticity. One company I use will sign their invoices, for example. I’ve never verified the signatures.
If you need to go to the technical effort of private group communication, running your own webmail service seems a lot easier and a lot more private.
I love PGP for other infra. I love my smartcards. But I can’t remember the last time I’ve used it for email :)
Unlikely. Since OpenSSL has no support for it (by extension this includes Apache and Nginx) because it's not a standard yet, adoption is very low. Also Chromium and by extension Chrome has no support for it.
Firefox does support a draft, but since Firefox usage numbers are somewhat low depending on what statistic you believe, this amounts to not much.
Of course the other option with email is that everything is in plaintext...
There are more secure options of course, but none of them are compatible with each other, and the most popular ones are more like instant messaging than email.
I wish there was a secure communication channel similar to email, but as ubiquitous as https.
My biggest issue with the new Thunderbird is the encrypted subjects. These break email for everyone not using TB, as TB is the only software that is able to show the real subject. Everyone else just gets „...“.
Encrypting subjects is both part of Autocrypt and there's a GPG plan floating around that features it. K9mail supports it (which is the only other client I use). Fairmail might too.
Well then you develop seperate tools for separate threat models. Covering all possible threat models is impossible and supporting many of them is a heavy maintenance burden that can easily lead to the standard user having their threat model compromised due to the added complexity.
Fair point. You could have "locked down" tools for standard users and "I can install my PGP smartcard extension" tools for power users. I guess in this case it was unfortunate that Thunderbird happened to be used by both the standard and the power users.
Cartering to power users isn't usually good for marketshare because it means you limit your market share to a small subset of the market. Making Thunderbird more accessible and making GPG more accessible, even if that means you can't support some niche use cases, is usually the better choice.
For a mass-market client, yes. But in an ideal world there would be alternatives that don't aim for market domination catered to a more advanced user base. Those could include functionality that would be unsafe for users who don't know exactly how it works.
The "real" solution is broken and does not work at all, it just crashes or hangs thunderbird.
Thunderbird is dead, has been dying for some time. Now that Mozilla is going bancrupt, users should rather look for alternatives and not waste time. Especially on a half-cooked encryption with obvious quality problems causing a possibly huge number of security problems.
If you need to prevent upgrade in Debian, Ubuntu, and other Debian package based distros add a version hold in apt's preferences by creating a 'pin' on the current version:
/etc/apt/preferences.d/thunderbird68
Package: thunderbird
Pin: version 1:68.*
Pin-Priority: 1000
Enigmail was working perfectly for me. I use it frequently and never had any issue.
Now I have to keep track of a second key chain. And honestly I don’t trust an app that specializes in email and views security as an add on rather than a priority.
112 comments
[ 2.0 ms ] story [ 284 ms ] threadMozilla used a library called RNP instead of integrating GPG.
RNP does not support many GPG features, such as smartcards.
Enigmail, the old method of using GnuPG with Thunderbird, is broken in 78.x.
Author recommends downgrading to 68.x and using Enigmail for advanced users.
Thunderbird, years ago for me.
If a human acts abusive towards me, it is logical to end the relationship, even if it is years old.
I am a tolerant person, so once or twice I may accept excuses and justifications, but after that, it's time to distance myself.
I don't see why it should be any different from software. If I feel like I am dependent on it and "can't" move away, all the more reason to prioritize finding alternatives.
It is irrelevant whether the causes are incompetence, malice, or "accidental", the result is all the same, and I cannot allow it.
Worse still - even many of the proprietary ones now rely on 3rd party servers for "cloud" features, or are bloated and ugly electron apps.
For me TB just works (especially because I'm locked at the ESR version, 68), however, I've never been extremly happy of it.
No offense intended, that's what your comment sounds like.
If you start looking, I bet you will find some options.
- online services, which are way worse Re: auto-updates, they do not even ask.
- mail clients with limited HTML support, which are not usable with many online stores I want to use.
Which mail client are you using?
Evolution is possibly the only valid competitor, however, it's not cross-platform as Thunderbird.
GnuPG is a program, not a library, and attempts to use it as one involve parsing its stdout (e.g. using GPGME)
Thunderbird renders untrusted HTML content and therefore is subject to a steady stream of CVEs and must stay absolutely up-to-date with Gecko
Gecko scaled back XUL and extension support, and WebExtensions are not sufficient to allow an Enigmail extension to run an installed binary.
But, more recently, mail campaigns have instead targeted Gmail, so "whatever Gmail renders" (this is not everything a browser renders, but is close). It's not feasible to implement a subset for this and do parallel CVE fixes.
It's worse than IE6. And to help your sanity, use mjml.
There's been a couple of working groups that have attempted to standardize HTML support in email, but they don't get very far on account of having almost no representation from anyone who actually works on email clients (on account of most of the interest being email marketers who want to complain about HTML support).
The actual support for HTML is probably these days mostly HTML5 (in terms of the actual parsing algorithm), with several elements unsupported, and the CSS support being very spotty. Many MUAs are using whitelists of elements to support (don't expect <video> to make it through, and especially not <iframe>), and scrubbing CSS themselves with whitelists. In effect, this means that virtually everything added in HTML5 probably won't work, so the support is more akin to HTML4 in that regard. Infamously, Outlook uses the same HTML rendering engine as Word, which is (was?) based on the IE 5.5 rendering engine.
Thunderbird will prompt the user to decide whether they want to render remote content. I'm not sure if that's the default setting, but that's how it's worked for me for many years over multiple installations.
I don't know about the situation in thunderbird, but in firefox this isn't entirely true. It is possible to communicate with a native executable using a JSON protocol over IPC, if that native executable is registered using a manifest file (See https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...). so it would be possible to use a wrapper executable that communicates with the extension using native messaging, and invokes gpg as needed. However, as I understand it, the native executable would need to be installed out-of-band (meaning it isn't part of the extension bundle itself).
Not directly related, but maybe Thunderbird shouldn't use Gecko to render emails. A smaller renderer with limited features may be sufficient and more secure.
Worst offense was when Outlook (and Express) used the IE rendering engine with JS in "local" (unrestricted) trust mode. Melissa/ILoveYou etc...
In fairness I also had the requirement of "is not USB" - but this is reasonable IMO (don't train your users to plug in USB key like things)
Honestly, I was really frustrated and disappointed by the upgrade. It’s not easy to roll it back, either, apparently. I haven’t risked it, but I sorely miss TB68 with Enigmail.
I'm obviously not happy for users who can't use TB now, but this external GPG-client stuff has to die. It never was userfriendly, and is only safe because the target audience is so small nobody bother. Passing around secrets on stdout?
Your first sentence was great, but the whole JS rant didn't land. I can't see how side-channels are relevant unless an attacker is already in the system, at which point they could just grab the plaintext.
So with evidence to the fact that TB does indeed execute attacker-supplied JS I would like to ask for a reference for your claim.
- The main issue is that your private key is supposed to be secret – not uploaded to a server you don't control. Of course Protonmail encrypts it, but passphrases are supposed to be an additional layer of security, not the only one. If Protonmail has a data breach, is compelled to surrender your keys or turns out to be untrustworthy, your messages are only as secure as your password.
- You cannot control when a web app is updated or verify that everyone else got the same update. So Protonmail – or an attacker that took control of their systems – could give you an update that gives them your unencrypted keys. That may be mostly a theoretical issue because few people do that with their local software either. Still, I'd trust the Debian/Ubuntu repositories more.
- Web apps have additional attack surfaces compared to local software. Malicious browser extensions can't access the data of local software, nor is local software suspectible to things like XHR attacks.
I initially tried to fix this by messing with my GPG keychain, because my underlying assumption was that they shared keychains. Imagine my shock when I realised my assumption was wrong! Fortunately I didn't lose anything important. Either way, having to maintain separate keychains is already enough of a deal-breaker for me... Maybe it will improve over time. I guess I'll have to wait and see, as I didn't back up my TB68 profile, so I can't downgrade :(
It's a small team, and this was announced I think nearly a year ago. It's a pity that apparently the import isn't without issue, but I can see how they expect expert users to be able to fix any problems they encounter.
The whole multiple keychain-thing is or was not communicated clearly anywhere ever, I've stumbled on this before. That's part of the bad design though, a keychain file would have made so much more sense and be easier to reason about than configuring it through arcane gpg incantations. I steered clear of it, but I'm surprised that Enigmail supported it (did it?).
Anyway, one 'internal' ring is a very good idea, and I'm happy TB went that way. That was a very conscious decision, as Openpgp.js development is much more active and open, so don't count on this changing.
The new UI could use some polishing (one or zero click encryption please!) but generally I am happy, and happy that I don't need Enigmail anymore.
And how is stdout not secure? We're talking about pipes here, not terminals.
I gave up on Thunderbird with the release of 78. Previously Emigmail was just functional enough once I got its finicky settings all dialed in.
Now I’ve gone all in on [MailMate](https://freron.com/) on macOS. Out of the box PGP support was only one of many pleasantries I found when I first tried this a few weeks ago. It’s dramatically changed my idea of how well a GUI MUA can actually work. Money well spent!
Then I fell out of the habit, so I'm curious in what kinds of scenarios you envision in which your habitual use of email signatures would help?
I use my PGP key (on my Yubikey) for SSH now.
This is largely due to the fact that my mail clients don't support PGP.
The new implementation is disastrous. I cannot read some e-mails encrypted by Symantec Encryption Desktop and UX needs some improvements too. Enigmail showed the cryptographic status of an e-mail with a conspicuous colored tab, this implementation indicates it somewhere on the edge of the screen in small letters.
Verifying received email is more problematic. There are far more of them, it can't get them from the GPG database I trust, it can't get them from a key server and manually importing them is again ... novel.
I understand the reasons for not wanting to use GPG to verify emails as they come from an untrusted source, not using it to sign emails could possibly be justified for forwarding emails from untrusted sources with attachments, not having nice way to import your trusted keys and keys from key servers I hope is only because this is version 1.
In particular, institutional email is accessible to the company. I am conservative in my emails assuming that everyone sees the message. Some of us have PGP keys and feel better to gossip :)
I use it for various other tasks too (exchanging API tokens, passwords, emailing myself documents, etc ).
And I'm a big victim to the note-taking pattern of "mail to self" and that gets a huge feature boost if you can do encrypted mail to self. I like it as my main secrets store because it's almost natural there to add a layer of mild obfuscation to your PINs and the few major passwords that get this treatment.
https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
It’s useful for closed circuits though, where you have a group of correspondents needing to prove their authenticity. One company I use will sign their invoices, for example. I’ve never verified the signatures.
If you need to go to the technical effort of private group communication, running your own webmail service seems a lot easier and a lot more private.
I love PGP for other infra. I love my smartcards. But I can’t remember the last time I’ve used it for email :)
I bet most of the non-supporting clients are simply either a bit outdated or had it disabled (probably by the client local AV engine).
Firefox does support a draft, but since Firefox usage numbers are somewhat low depending on what statistic you believe, this amounts to not much.
There are more secure options of course, but none of them are compatible with each other, and the most popular ones are more like instant messaging than email.
I wish there was a secure communication channel similar to email, but as ubiquitous as https.
Dear Thunderbird developers, if someone uses gnupg assume they want to use gnupg and not some self-cooked, half-working solution.
Thunderbird is dead, has been dying for some time. Now that Mozilla is going bancrupt, users should rather look for alternatives and not waste time. Especially on a half-cooked encryption with obvious quality problems causing a possibly huge number of security problems.
If you added a version pin by adding a file... then remove the version pin by removing the file.
Now I have to keep track of a second key chain. And honestly I don’t trust an app that specializes in email and views security as an add on rather than a priority.