6 ms·
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 deta
by Xophmeister 6y ago
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.
- woodson 6y agoBackup your profile before the update. Thunderbird 78 makes non-backward-compatible changes to it, so you cannot downgrade to TB68.
- brnt 6y agoThunderbord 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?
- krageon 6y agoA 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.
- zaarn 6y agoBefore 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.
- corty 6y agoStdout 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).
- ficklepickle 6y agoEmail 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.
- corty 6y ago"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.
- xrisk 6y agoSince when did Protonmail become anything more than snake oil?
- 35803288 6y agoI would like to hear more about this. I'm not an expert or programmer, just a user. Thanks
- anoncake 6y agoThree 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.
- Xophmeister 6y agoI'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 :(
- brnt 6y agoOpenPGP.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.
- anoncake 6y agoI 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.
- ficklepickle 6y agoI 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.
- kaiengert 6y agoNo, Thunderbird 78 doesn't use OpenPGP.js - it uses RNP and Botan for OpenPGP.