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.