It depends on how the browser rejects favicons? If the browser reports the icon is already cached, I agree (assuming the reports are indistinguishable). But maybe it just never downloads the icon, for example.
Even if you ONLY care about encrypting files presumably you want to be able to decrypt them far into the future, with confidence no one else can do so.
If that is the case, you probably want:
1. a long lived keychain
2. a way to securely load private keys into smartcards such that they cannot be stolen by malware
3. a strategy to recover lost keys
4. a strategy to migrate from one keychain to another one
5. a way to notify people/software to stop encrypting data to your old key
6. a way to switch between multiple competing software implementations with a long established spec
The PGP ecosystem has you covered on all points. Age does few of these, and none of them well.
Doing things the right way takes a bit more up front thought and time, and you will thank yourself later.
That said, for the sake of compatibility, keyfork keys can be used with any pgp toolchain, as well as with signify, age, or whatever.
It’s unclear to me any stateful keychains are implied here. The decrypting system has N number of keys available. It tries to authenticate the ciphertext with those N keys. If the ciphertext authenticates, then return the decrypted cleartext.
What’s more, it’s unclear to me why point 5 belongs in the cryptosystem layer (such as with PGP) rather than on some higher, more adaptable layer. All that is needed for that higher layer to “compile down to” or emit some kind of key allowlist or denylist that can be consumed by the cryptosystem layer beneath it. The work-in-progress VOA[0] spec is an example of such an upper layer.
> It’s unclear to me any stateful keychains are implied here.
Encrypted files are encrypted to a key. It could be a one time use key encrypted to another key as PGP and Age both do, but still there is a long lived secret a user must maintain somewhere, somehow, and have a strategy for backup, rotation, discovery, validation, etc etc.
> it’s unclear to me why point 5 belongs in the cryptosystem layer (such as with PGP) rather than on some higher, more adaptable layer.
There are a ton of other ways these problems could be solved. If we had a time machine we would go back and design way different tools and specs to address the problems PGP solves. We would redesign the internet too.
What I take issue with is people recommending age or minisign or signing with ssh keys when all of these just pretend the problems PGP solves do not exist, and thus set people up to fail.
> but still there is a long lived secret a user must maintain somewhere
Of course. I'm not suggesting that there's no need to have long-lived private key material. But that does not require some thick GPG-keyring-style concept (especially one that includes both public and private key material). Something like a directory of private keys (like with SSH) fits the bill here and yet bears precious little resemblance to GPG's system.
> have a strategy for backup, rotation, discovery, validation, etc etc
Again, I see no reason to bake this stuff (I'll call it "identity management") deeply into the cryptosystem itself. Especially because different encryption use-cases have vastly different needs. The identity management needed for a one-time message exchange between humans shares little structural similarity to that needed for authenticating OS packages from multiple parties. These two use cases are almost entirely disjoint, I daresay. To the point that any effort to devise a shared abstraction will only muddy the waters since there is so little intrinsic similarity.
> What I take issue with is people recommending age or minisign or signing with ssh keys when all of these just pretend the problems PGP solves do not exist, and thus set people up to fail.
I can agree with this for sure. If you need these various features, then age et al. do not fit the bill.
On the other hand, in cases where these systems have adequate functionality or can be shimmed up by other systems, they're lightweight and easy for users to comprehend.
Take commit-signing with SSH keys to provide verification mediated by GitHub. Everyone (lol) knows how to generate and manage an SSH key. Easy enough to set up git for signing with that key. Then GitHub uses its own identity layer to show users what commits are verified and which aren't. From the user's perspective, it's super lightweight, easy. When it comes to cryptographic signatures with long-lived identities, it basically doesn't get easier than this.
Of course, that GitHub example misses some features, and isn't perfect. But it captures a lot of the value of signing with a bare minimum of error-prone work for the user.
Wait, how does minisign "pretend the problems PGP solves do not exist"? Minisign is an example of a purpose-built tool designed specifically to address a problem PGP attempts to solve. We're now talking about two different tools each of which addresses something in PGP's scope. If we keep fleshing out PGP's scope, we'll keep finding more tools like this, because very few people operationalize PGP and lots of people have the problems PGP attempts to solve.
Your argument doesn't cohere.
I feel like the rhetorical sleight of hand PGP advocates too often fall back on is the idea that while there may be tools that do some of what PGP does, and those tools put together may comprise a superset of PGP's functionality, there is no one tool that does everything PGP does by itself. But that's the whole point. Part of what makes PGP so bad is that it's a Swiss Army Knife.
Minisign and Age entirely dodge the actually hardest problem with humans using cryptography, that PGP puts front and center: identity and public key discovery. You cannot just skip these!
If a human focused cryptography tool gives a user no way to know if they are encrypting to the correct public key of someone else, or no way to distinguish a real signature from one of an impersonator, then the tools failed to do their job.
Age is maybe useful for personal encryption use cases, but it is no way a replacement for all encryption use cases of PGP, especially between humans. Let alone signing and authentication which would be a prerequisite to do this safely.
I love that age lets one reuse ssh identities and thus identity sharing systems. The single most useful thing I ever wrote was a tool to sync github identities with age.
https://github.com/tarasglek/github-to-sops
This way you get git for change tracking on your secrets and who-has-access-to-secrets and key rotation and this can be trivially expanded to other forges.
Its easy to introduce age this way into any modern project whereas gpg would-ve been a non started on most teams I worked on.
disclaimer: this was mostly vibe-coded because I really did not want to work on this and wasnt sure if teammates would adopt it. Then it just worked, so stayed ugly inside
PGP does an absolutely dreadful job of key discovery, and further, there is no reason to couple one mode of "key discovery" to a signing tool. Different business domains will have different optimal key discovery architectures.
My guess is that at this point more professional environments (think on the level of "companies and projects") have integrated age and minisign than have integrated PGP, which is striking given how long PGP has had to demonstrate success. In 2025, if you built a new identity system for, say, code, virtual machine or container provenance, or secure messaging, your competent security team would very likely shoot you down.
This is just another instance of the same sleight of hand I identified upthread. It's actually bad that PGP does all this stuff, for the simple reason that different real-world problems have different cryptography requirements. For that reason, competently built systems don't do what the PGP ecosystem does, of fielding a Swiss Army Knife instead of a chef's knife or a table saw. Then the PGP ecosystem tries to ding those tools for not repeating PGP's mistake.
You're not responding to the main point. Here's tptacek's wording:
> PGP does an absolutely dreadful job of key discovery, and further, there is no reason to couple one mode of "key discovery" to a signing tool. Different business domains will have different optimal key discovery architectures.
Here's how I expressed it to you:
> Again, I see no reason to bake this stuff (I'll call it "identity management") deeply into the cryptosystem itself. Especially because different encryption use-cases have vastly different needs. The identity management needed for a one-time message exchange between humans shares little structural similarity to that needed for authenticating OS packages from multiple parties. These two use cases are almost entirely disjoint, I daresay. To the point that any effort to devise a shared abstraction will only muddy the waters since there is so little intrinsic similarity.
age has Yubikey support. The idea that the PGP ecosystem "has you covered" on all these points is a bold claim. Certainly people talk about all these things, but when that system is put to the test, it rarely holds up. See for instance the keyserver fiasco.
Barely. Age has Yubikey support with no reasonable long term key discovery, backup, or rotation strategy as far as I can tell. All things modern PGP tooling supports.
But this is what happens when people try to re-invent the wheel without thinking through all the problems the original solution solved.
Also I do put these systems to the test, regularly, and rest billions of dollars of infrastructure on them.
Anyone is free to hit up my team in our public channels with any PGP gotchas. Happy to help.
It is easy to point at past black eyes of any technology, but I stand by PGP for the use cases we recommend it for today as the least bad option for those use cases.
Also, Hagrid keyservers (openpgp.org) do email verification now and are a new generation of keysever built from scratch. The legacy ones are a mess and can be ignored.
Today though, Web Key Discovery, PGP DNS records,and Keyoxide are much better ways to discover and distribute keys and signatures now.
I think even brilliant cryptographers can be wrong, or acting on strong biases formed from a limited perspective. In this case I think they have not thought about personal cryptographic key management and how people use tools like PGP in the wild well enough.
An engineer coming from a corporate world where everyone is comfortable with a model of centralized backups, centralized identity, and centralized trust is going to have a very different perspective than say, a Linux distribution maintainer, or those maintaining they core backbone of the internet.
I am closer to the latter camp, and obviously have my own biases here, but in spite of them I package Age in stagex, and we support it in keyfork, just so people have choices. Choices are always a good thing.
That said, it is my opinion that age does not even begin to approach the threat model or use cases PGP solves for. It does one thing, and it does not even do that thing as well as PGP does in most situations I can think of.
Just because someone is experienced in cryptography does not mean they have had significant exposure to environments where decentralized identity and trust are a hard requirement and where no alternatives to PGP exist, and where there is no customer service or IT team to bail you out, which really changes how we tend to think about these problems.
In my experience cryptography engineers that work on decentralized open source systems like Tor, blockchains, Linux distributions, etc, tend to strongly favor solutions like PGP as not "good" but the "least bad" option to avoid any single point of trust or failure.
Those that have spent their careers in the proprietary FAANG world tend to support using solutions like Fulcio or sigstore and using OIDC to let a central party sign for you with "keyless signing", which to me, is total nonsense. I assume anything that I cannot verify the integrity of for myself to be compromised.
I think Filippo Valsorda has in fact thought pretty hard about the issues you're talking about, and that, by contrast, the track record of the PGP community on those same issues is pretty dismal.
I think the tldr of their point is that Filippo thought a lot about cryptography but not about actual users or their requirements. What he thinks are cruft are actual features that users depend on
If I am wrong I challenge you to point at a well specified replacement for PGP with a diversity of competing implementations as a decentralized cryptographic identity and trust system for open source software supply chain signing, authentication, and peer to peer encryption with a variety of smartcard generation, usage, and backup solutions better for every situation PGP is used in today.
Also a solution that significantly reduces attack surface enough to motivate a migration from PGP in all the areas it is used, and a specific strategy to migrate everything to it.
Also form a standards team to maintain the spec to keep all implementations compatible so this work is useful long term.
If all of that happened I would seriously evaluate it and likely even help promote it. Few understand the shortcomings of PGP better than those of us that heavily rely on it!
Until then I suggest improving upon what already exists, or at the very least stop steering people away from the best effort solutions we have today and all the hard work from hundreds of people that go into maintaining them for free.
I'm not the one insulting Filippo Valsorda, for no apparent reason (any of your points could have been made without criticizing him), when he's not present to defend himself in this thread. The onus is squarely on you here. You won't succeed, though, so I don't blame you for not wasting the time.
I recently did an arch with zfs root setup. You have to make a custom install ISO that has the zfs module to do it. After it's installed the main annoyance is the zfs module only works with certain kernel versions and often arch has updated the kernel to a version not supported. There's a repo with pinned kernel versions or you can just use the lts kernel.
FreeBSD is much easier but I needed better Linux compatibility for this machine
We run ZFS for a system at work on linux. Yea, it isn't as seamless and nice on FreeBSD. Only reason we aren't running FreeBSD is the application that needs to access that storage is .NET, and no .NET support for FreeBSD.
Will check this out! I knew there was a group who had a version working, but it wasn't upstreamed and last I check was still stuck at .NET 5. While I would like to migrate from Debian to FreeBSD, probably won't get management to okay that with current services, but future one, maybe!
Makes sense, out of curiosity have you tried the linux jails that Bastille offers? [0]
They're still considered experimental so I wouldn't run it for production but I wonder how well .Net would run in one. The whole container could be a zfs dataset, which would be interesting.
People can fork my code all they want but to anyone actually paying attention it's obvious mine is the real one. If theirs is actually better and they actually put in more work then so be it.
But in reality the original is often the best updated and the forks will fall behind because they have to merge your changes and you don't have to do that.
I built a reverse proxy server for this kind of usecase specifically. I have a chroot launcher with a simple config file and the reverse proxy is auto configured over RPC and automatically acts as a CA root so internal communication is HTTPS. You can also set the API key as an env var and just run your binary on the command line for testing and it will auto configure and be available on your URL with https.
It's a bad time for me to be mentioning it because I have a major update that's not quite ready to release that changes some client APIs and makes the whole thing much nicer with fully automatic lets encrypt. I haven't had the space to work on it for a while unfortunately.
Google writes articles like these every week and hangs them in the bathroom. It's meant to be a quick one page tip thing. That's why the example isn't super realistic, it has to be short.
There's a link with more info at the top. I'm not sure why this one in particular made it to the front page of HN.
It's worse than parroting advice that's not applicable. It tells you what you told it to tell you. It's very easy to get it to reinforce your negative feelings. That's how the psychosis stuff happens, it amplifies what you put into it.
We still find evidence of life on earth from billions of years ago that was not erased by billions of years of their successors. I doubt you have anything to worry about.
But imagine the value of finding _any_ living RNA based life which is clearly not from earth before we travel to other stars.
It's one thing to know there was once life, and to know basically nothing about it. But being able to date it in the tree of life (or forest of life?) is monumentally more relevant to understand our place among the stars.
