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.

Backup your profile before the update. Thunderbird 78 makes non-backward-compatible changes to it, so you cannot downgrade to TB68.

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?

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.

I think the security issues come from parsing text rather than stdout itself. I vaguely recall reading about such an issue a year or two ago.

No, Thunderbird 78 doesn't use OpenPGP.js - it uses RNP and Botan for OpenPGP.

Thanks for the correction! Did this change in the development of TB78 or do I seriously misremember reading about it in the initial announcements?

Maybe it was mentioned as one of the technologies we consider, because it took us a while to make the final decision.

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.

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.

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.

Since when did Protonmail become anything more than snake oil?

I would like to hear more about this. I'm not an expert or programmer, just a user. Thanks

Three issues:

- 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.

Summary:

Mozilla 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.

Backstory:

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.

> 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.

Or... disable any JS runtime in a webview/iframe for the message. I get using an HTML rendering engine, I don't get ever enabling JS.

Worst offense was when Outlook (and Express) used the IE rendering engine with JS in "local" (unrestricted) trust mode. Melissa/ILoveYou etc...

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.

Automatic playing of audio or video, and no eval support in css would also be a good idea.

> 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.

That's just for images. There could still be exploits in the HTML itself executing locally.

Is this the case if you have Thunderbird set to view message body as plain text?

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?

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.

There is no standard HTML version for email, the same way there is no standard HTML version for a website. The contents can reasonably be anything.

Follow up question: What parts of html do you need implement to render 99% of emails decently accurately?

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.

Unfortunately Outlook has a pretty big market share in corporate world and if you're serious about your emails, you still have to support it.

It's worse than IE6. And to help your sanity, use mjml.

Or just don't send weird shit in emails.

Email html rendering is a giant pile of steaming dino dung. No matter how you implement it, you will absolutely break emails.

Thunderbird has simplified html viewer, no css etc, works pretty well.

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.

KMail is pretty great IME.

Sounds like a pretty reasonable personal choice to me, I don’t know why you’re being downvoted without any explanatory comments.

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.

I did start looking, and I didn’t find anything’ better. It seems most of the people who cared about local mail clients moved to either:

- 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?

An axiom of cryptographic tool design: there are no advanced users. Designs that ignore the axiom will always create dangerous failure modes.

A consequence of taking this axiom to the extreme is that you might not be able to support many diverse threat models though.

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.

Well, that is what extensions are for in Thunderbird. As long as atleast one poweruser is willing, they can write the powertools.

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 :)

This is somewhat the case as SNI is unencrypted.

Could you expand on that please? SNI is not the full URL or am I missing something?

But there's eSNI.

Which is a very new technology, and not widely deployed yet.

I get about 5k unique visitors from my websites, additional 20k visitors from a community project I'm in. We see about 30 - 40% eSNI Adoption.

And that is just client support. For eSNI to work, both client and server must support it.

Adoption, not support, meaning the clients and server both support it.

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).

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.

Well, again, we see about 20-40% eSNI activity based on our connection data, of about 60k monthly users.

Not plausible unless you have a very specific userbase, ie Firefox users mostly.

A draft. OpenSSL devs wait for it to be finished.

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.

True. But mostly I’m cool knowing that I delivered over TLS.

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?

I've just switched to Postbox. It is a polished version of T-bird. And works with Enigmail to integrate with gpg.

You can't prove what you did not write.

I did but I stopped as soon as I noticed that most of my private communications could be handled as instant messages, so I use Signal more.

I use my PGP key (on my Yubikey) for SSH now.

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 do not. People I write to don't have PGP configured in their client, and e-mail will never be secure anyway.

https://latacora.micro.blog/2020/02/19/stop-using-encrypted....

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.

I use it frequently.

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 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 receive a fair number of PGP encrypted messages. I don't usually send them unless I am sending something that needs to remain private.

This is largely due to the fact that my mail clients don't support PGP.

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.

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.

I do. In fact, all of my work emails are GPG-signed by default. But I never liked Thunderbird, I've been using claws-mail for more than 15 years.

In the past 20 years I’ve used PGP (for email) about... three or four times. It just isn’t worth it. There are better tools now, such as Signal.

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 do not. You should do a straw poll in a separate ask HN. I'm curious about this too.

I don't. It doesn't make sense for 99.9% of my communications. I'm also not sure my typical recipient would know how to handle signed emails.

I sign all mail. I use encryption for some conversations.

I do not. I tried it a number of times and while I can get the hang of it it's a lt of bother when no-one else I know uses it either.

I‘m using it very often in our conpany. The TB78 implementation would break many workflows and security aspects.

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.

Never.

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

To be fair trying to get a decent hardware key is a lesson in "no longer sold" from any list I found when looking into it a year back for GPG.

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)

You can use a traditional smartcard to store your GPG keys. That should meet your requirements?

You can even use a Yubikey.

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

How would you later remove the pin?

Just like climbing a tree, the best way down is usually the inverse of the way you got up.

If you added a version pin by adding a file... then remove the version pin by removing the file.

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.

Is that optional, or automatically enabled with no way to disable?

The latter it seems: https://support.mozilla.org/en-US/kb/openpgp-thunderbird-how...

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.

The real solution is to use gnupg as external program, it's hinted at in the FAQs and a walkthrough is here: https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards#Conf...

Dear Thunderbird developers, if someone uses gnupg assume they want to use gnupg and not some self-cooked, half-working solution.

If you read the article the author mentions that it doesnt work at all,

It works totally for me, sorry. Using a smartcard so Thunderbird doesn't give me another option right now.

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.

I'm using Debian's 78.5.0. It uses external gpg by default and works flawlessly for me with my hardware USB token.

Does that mean Debian developers patch Thunderbird to remove the new GPG implementation?