Hacker News new | past | comments | ask | show | jobs | submit login

First, thanks enormously for writing this -- and for all the other recent articles that have appeared here the vein of "PGP is as bad as it is unpleasant to use". It's a point I didn't really appreciate (at least as much as I (sh/c)ould have) and I'm sure I'm not alone.

It seems that the state of package distribution for many distributions is poor, security-wise. (OpenBSD, to nobody's surprise, is an exception.) For instance, archlinux (I'm loyal) signs packages with PGP[1] and, for source-built packages, encourages integrity checks with MD5. My recollection is that, about 5 years ago, MD5 was supposed to be replaced with SHAxxx. Am I misinterpreting this? Is this actually Perfectly Okay for what a distro is trying to accomplish with package distribution?

(I'm particularly suspicious of the source-built package system, which consists of a bunch of files saying "download this tarball and compiler. MD5 of the tarball should be xyz." I'm pretty confident that's not okay.)

Okay, now moving from package distribution to messaging, and again looking at the state of my favorite system. How am I supposed to message securely? The best nix messaging tools are all based around email. Even when I can get the PGP or S/MIME or whatever toolset to work (let's face it, that's at least 45 minutes down the drain), it's clear that I'm not in good shape security-wise.

I should use signal, apparently. Great. Just a few problems: (1) no archlinux signal package, (2) I'm guessing I can't use it from the terminal, and (3) most severely, it seems signal has incomplete desktop support. In particular, I need to first set up signal on my phone. Well, let's face facts: I have a cheap phone from a hard-to-trust hardware vendor, and I think there's a >5% chance it's running some sort of spyware. (The last phone I had genuinely did have malware: there were ads showing in the file manager, among other bizarre behaviors.) So in order to use signal on my desktop, I need to buy a new phone? That's even worse, usability-wise, than PGP.

Is... is it really this bad? I'm getting the sense that the desktop linux community has completely dropped the ball on this one. (And perhaps more generally desktop mac/windows... I wouldn't know.)

[1] Perhaps not so bad, since the keyring is distributed with the system -- but how was the original download verified? Options are: PGP, MD5, SHA1, with the choice left up to the user. That can't be right.




Arch Linux's pacman is not a good example of a secure package distribution system (especially not the AUR, where you are downloading all the bits from the internet and building them yourself as your own user or even sometimes as root). They didn't do any package signing or verification at all until (shockingly) recently -- less than 10 years ago IIRC. I am a huge fan of Arch's philosophy but am definitely not a fan of the design of their package distribution system.

If you look at systems like Debian-derivatives or RPM-based distros (openSUSE/SLES, and Fedora/CentOS/RHEL) the cryptosystems are far better designed. In the particular case of openSUSE, the AUR-equivalent (home: projects on OBS) are all signed using per-user keys that are not managed by users -- eliminating almost all of the problems with that system. Yeah, you still have to trust the package maintainer to be sure what they're doing, but that should be expected. I believe the same is true for Fedora's COPR.

[Disclaimer: I work for SUSE and contribute to openSUSE.]


If you have to trust the package maintainer what's the difference between having package signed by them or not?

For the record AUR packages can use GPG keys, see e.g. GPGKEY variable: https://wiki.archlinux.org/index.php/Makepkg#Configuration

Arch also uses Web of Trust to introduce Trusted Users: https://www.archlinux.org/master-keys/ so I wouldn't call "less than 10 years" as a disadvantage, but rather advantage - they have seen problems with alternative designs (e.g. Debian's curated keyring) and came up with something better.


aur is a system. you can of course make your own pkg's without sharing if you so chose.

responsibility is assumed when using others for any can submit there. that said there are signatures that can be verified ie available.


I don't know where you found MD5, most PKGBUILDs have `sha256sums` in them.

Package signing is (hot take!) overrated and can be somewhat theater. It helps if your package manager connects to third party mirrors, but otherwise, the only threat it protects against is "the https server is compromised but the package build farm is not". I don't know why anyone would worry so much about that.


> the only threat it protects against is "the https server is compromised but the package build farm is not"

Looking at an /etc/apt/sources.list, it doesn't look Ubuntu is using HTTPS for package distribution. Since you don't need both package signing and transport security, and I suspect that the list of packages you're downloading is a fairly trivial conversation length analysis anyways, I don't think the setup of signed packages over HTTP is meaningfully less secure than unsigned packages over HTTPS.


Signal does a great job of supporting activists. That's basically its intentional product focus. Everything an open source proponent engineer might want to promote is secondary. The focus on activism and trying to deal with large actors definitely looks like #1. Everything else about their product is secondary to that.

Signal's product focus has been at best un-encouraging to those who want to use it for anything else. Federation, I'm looking at you, but you've also got to take it in the sense that every single vendor that embraced the only realistic messaging federation standard of the 21st century went on to embrace and extinguish it in less than a decade.

This speaks to a few problems: 1. Messaging is hard 2. Security is hard 3. Logic about security is hard to reason. 4. Historically, anyone paid enough to care about this space hasn't had any sort of public interest at heart.

Any application that combines any of the three falls squarely into what the people at Latacora and the like would call a high risk application. I might disagree with much of their analysis, but in the lens of risk control, they are perfectly correct.

If you're trying to figure out how we got here, you've also got to realize that there was an avalanche of government and commercial entities whose goals are not in alignment with say, those who think the optimal solution is a home rolled provable trustless security system.

For myself and many engineers I'd bet, I'd say that's where we thought things should go in the 90s and early aughts. Some things are better now, but most are much worse.

Society and encryption's implications I would say have caught up with each other, and theres definitely something found wanting. There's definitely say a market opportunity there, but there's also another big challenge that I read reviewing a discussion about package signing lately: "Nobody in this space gets paid enough to care."

That's what separates people like Signal, even if some of the engineering crowd doesn't like the way they delivered.

This is a bit of a ramble, so there's two afterwords:

1. Much of the morass about PGP is explicitly due to the environment, space, and time in which it was developed. This does not boil down merely to 'it wasn't known how to do it better.' There were decisions and compromises made. I think the writer at Latacora is not giving the history of the piece justice. That's OK though, because that's not the crux of their argument. It would be good though I think if they gave that a further explanation than why things like the byzantine packet format are impossible to explain, even if that explanation were only a footnote and reference. (Writing the history of how it got there is absolutely doable, but it would make for a dryly humorous history, at best.)

2: The open source and (linux/others?) distro community has tried hard, more than once to make this work. The development, design, and implementation burden though, is gargantuan. The overarching goal was basically to be compatible with every commercial system and maybe do one or two things better. What the article casts as purely a liability was the only way to get practical encryption over the internet well into the early '00s.'

Regardless of all that though, PGP is still a technical nightmare. If you dismiss it though, even when we have better components, I worry that we'd only repeat these mistakes. If you work in any sort of crypto/encryption dependent enterprise, please find and study the history. Don't just take the (well considered) indictment of PGP at face value. There's important lessons to be learned there.


The byzantine packet format in PGP buys PGP nothing. There is no engineering reason for PGP to work that way, and PGP continues to suffer security issues because of it. I'm not arguing that PGP's original designers were incompetent, nor am I considering that argument, because it is totally uninteresting to me. What is relevant to me is the fact that today, that design is costly and bad. What more is there to think about? We should get rid of bad cryptography and replace it with good cryptography.


You make a good point. The design is costly and bad, I hope I wasn't arguing to retain it for historical reasons or anything like that. I do believe that the history of how PGP got there, and how its ecosystem became the sort of hydra that it is should be kept in mind for anyone trying to build a replacement.

The commercial factors that drove the engineering there I think is a real risk for any cryptosystem implementor, especially if they are trying to build or retain a userbase.


I can probably agree on the packet format, it's excessively flexible and easy to implement insecurely.


You can probably agree about the PGP packet design?


Yes, it depends on what you mean. The packets themselves aren't a big deal to me, it's more the ability to construct them in arbitrary ways that concerns me.


> Signal does a great job of supporting activists.

I don’t think it practically achieves this. Even now, Signal is an unreliable platform to communicate with. One can’t be sure if the message will reach in a timely manner (like a few seconds or several seconds) or even reach at all. The UX and feature set are also far behind something like Wire.

I’ll accept that Signal has a strong and reputed protocol, and has take some strong measures on security and privacy. But everything else about is truly meh, to put it mildly.

Please don’t dismiss these points about reliability saying it has never failed for you or someone you know. It routinely fails for people I know, and that’s all that matters when recommending a messenger platform to others.

Signal has made it seem like security is easy to focus on (though a lot of thought and work has gone into it), but has shown that UX or pretty hard and that running a platform is even harder (even at Signal’s scale, which I presume is a fraction of other platforms).


Signal is beholden to the whims of Google due to their reliance upon the google cloud messaging stack. All messages are delivered based upon something outside of their control (whether Google decides they have enough priority to wake the modem). If you are on your phone all the time and have signal open it is usually instantaneous but say your phone is usually dormant it can be hours before a notification pops up. I'm not sure how different the situation is on iOS or if this is even avoidable with the current mobile duopoly. I find that the unreliability of signal precludes exclusive use of it so I tend to route a lot of communication through SMS via signal or double send. This is not high security stuff. It does seem like a relic of our age that chat is considered the preeminent form of communication. I think long form and long lasting texts like e-mail are valuable but maybe I'm just long-winded.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: