Gpg.fail • Hacker News Board

Re: Gpg.fail

#171

Post by tptacek » Sun, Dec 28, 2025, 4:13 AM UTC

pornel wrote: post #165

rurban wrote: post #19

Earlier quoted context omitted.

They presented critical parser flaws in all major PGP implementations, not just GNU PGP, also sequoia, minisign and age. But gpg made the worst impression to us. wontfix

Sequoia is mentioned in only one vulnerability for supporting lines much longer than gpg. gpg silently truncates and discards long base64 lines and sequoia does not. So the vulnerability is in ability to feed more data to sequoia which doesn't have the silent data loss of gpg. In all other cases they only used sequoia as a tool to build data for demonstrating gpg vulnerabilities.

The vulnerability that opens the talk, where they walk through verifying a Linux ISO's signature and hash and then boot into a malicious image, impacts both GnuPG and Sequoia.

Re: Gpg.fail

#172

Post by ekjhgkejhgk » Sun, Dec 28, 2025, 4:14 AM UTC

loop22 wrote: post #151

ekjhgkejhgk wrote: post #148

Is anyone else worried that a lot of people coming from the Rust world contribute to free software and mindlessly slap on it MIT license because it's "the default license"? (Yes, I've had someone say this to me, no joke) GnuPG for all its flaws has a copyleft license (GPL3) making it difficult to "embrace extend extinguish". If you replace it with a project that becomes more successful but has a less protective (for…

I think that's a feature not a bug for upstream projects encouraging these rewrites.

It's harmful if the license of the rewrites if less protective of users, and then the rewrite ends up being very popular.

Re: Gpg.fail

#173

Post by Avamander » Sun, Dec 28, 2025, 4:18 AM UTC

ameliaquining wrote: post #60

elric wrote: post #13

This is depressing. From what I can piece together while the site is down, it seems like they've uncovered 14 exploitable vulnerabilities in GnuPG, of which most remain unpatched. Some of those are apparently met by refusal to patch by the maintainer. Maybe there are good reasons for this refusal, maybe someone else can chime in on that? Is this another case of XKCD-2347? Or is there something else going on? Pretty m…

If by "pretty much every Linux distro depends on PGP being pretty secure" you're referring to its use to sign packages in Linux package managers, it's worth noting that they use PGP in fairly narrowly constrained ways; in particular, the data is often already trusted because it was downloaded over HTTPS from a trusted server (making PGP kind of redundant in some ways). So most PGP vulnerabilities don't affect them. I…

Debian and most Debian derivatives have HTTP-only mirrors. Which I've found absolutely crazy for years. Though nobody seems to care. Maybe it'll change this time around.

Though this type of juggling knives is not unique to Linux. AMD and many other hardware vendors ship executables over unencrypted connections for Windows. All just hoping that not a single similar vulnerability or confusion can be found.

Re: Gpg.fail

#174

Post by stackghost » Sun, Dec 28, 2025, 4:29 AM UTC

johnisgood wrote: post #129

soatok wrote: post #117

Earlier quoted context omitted.

(This is some_furry, I'm currently rate-limited. I thought this warranted a reply, so I switched to this account to break past the limit for a single comment.) > This statement is generic and misleading. It may be generic, but it's not misleading. > Using long-lived keys for confidentiality is bad in real-time messaging, but for non-ephemeral use cases (file encryption, backups, archives) it is completely fine. What…

You introduced "short-lived" vs "long-lived", not me. Long-lived as wall-clock time (months, years) is the default interpretation in this context. The Alice / Bob comparison is asymmetric in a misleading way. You state Bob Ltd retains all private keys indefinitely. A Heartbleed-style attack on their key storage infrastructure still compromises 30 years of backups, not 90 days. Rotation only helps if only the current…

>Personal backup encryption with a long-lived key, passphrase-protected private key, and offline storage is a legitimate threat model

... If you're going to use a passphrase anyway why not just use a symmetric cipher?

In fact for file storage why not use an encrypted disk volume so you don't need to use PGP?

Re: Gpg.fail

#175

Post by Avamander » Sun, Dec 28, 2025, 4:35 AM UTC

akerl_ wrote: post #70

alphazard wrote: post #61

Earlier quoted context omitted.

It's a fundamentally bad idea to have a single key that applications are supposed to look for in a particular place, and then use to sign things. There is inherent complexity involved in making multi-context key use safe, and it's better to just avoid it architecturally. Keys (even quantum safe) are small enough that having one per application is not a problem at all. If an application needs multi-context, they can h…

> The disk is fully encrypted, and applications should be isolated from one another. For most apps on non-mobile devices, there isn't filesystem isolation between apps. Disk/device-level encryption solves for a totally different threat model; Apple/Microsoft/Google all ship encrypted storage for secrets (Keychain, Credential Manager, etc), because restricting key material access within the OS has merit. > I'm sure th…

> For most apps on non-mobile devices, there isn't filesystem isolation between apps.

If there isn't there should be. At least my Flatpaks are isolated from each other.

> Apple/Microsoft/Google all ship encrypted storage for secrets (Keychain, Credential Manager, etc), because restricting key material access within the OS has merit.

The Linux equivalents are suspicious and stuck in the past to say the least. Depending on them is extra tedious on top of the tediousness of any PGP keyrings, god forbid a combination of the two.

> Basically everything in PGP/GPG predates the existence of "corporate security circles".

Then we know where this stuff came from.

Re: Gpg.fail

#176

Post by Avamander » Sun, Dec 28, 2025, 4:42 AM UTC

65a wrote: post #124

kaoD wrote: post #73

Earlier quoted context omitted.

This is not the first time I see "secure key distribution" mentioned in HN+(GPG alternatives) context and I'm a bit puzzled. What do you mean? Web of Trust? Keyservers? A combination of both? Under what use case?

In a signature context, you probably want someone else to know that "you" signed it (I can think of other cases, but that's the usual one). The way to do that requires them to know that the key which signed the data belongs to you. My only point is that this is actually the hard part, which any "replacement" crypto system needs to solve for, and that solving that is hard (none of the methods are particularly good).

> The way to do that requires them to know that the key which signed the data belongs to you.

This is something S/MIME does and I wouldn't say it doesn't do so well. You can start from mailbox validation and that already beats everything PGP has to offer in terms of ownership validation. If you do identity validation or it's a national PKI issuing the certificate (like in some countries) it's a very strong guarantee of ownership. Coughing baby (PGP) vs hydrogen bomb level of difference.

It much more sounds to me like an excuse to use PGP when it doesn't even remotely offer what you want from a replacement.

Re: Gpg.fail

#177

Post by grayhatter » Sun, Dec 28, 2025, 4:50 AM UTC

ekjhgkejhgk wrote: post #148

Is anyone else worried that a lot of people coming from the Rust world contribute to free software and mindlessly slap on it MIT license because it's "the default license"? (Yes, I've had someone say this to me, no joke) GnuPG for all its flaws has a copyleft license (GPL3) making it difficult to "embrace extend extinguish". If you replace it with a project that becomes more successful but has a less protective (for…

> Is anyone else worried that [...] the Rust world [...] slap on it MIT license because it's [reason you don't like]?

No... I don't think that's how software works. Do you have an example of that happening? Has any foss project lost control of the "best" version of some software?

> Not everything in software is about features.

I mean, I would happily make the argument that the ability to use code however I want without needing to give you, (the people,) permission to use my work without following my rules a feature. But then, stopping someone from using something in a way you don't like, is just another feature of GPL software too, is it not?

Re: Gpg.fail

#178

Post by grayhatter » Sun, Dec 28, 2025, 4:57 AM UTC

ekjhgkejhgk wrote: post #168

rendaw wrote: post #158

Earlier quoted context omitted.

How would MIT make anyone lose control of it?

The way it works is: A company adopts some software with a free but not copyleft license. Adopts means they declare "this is good, we will use it". Developers help develop the software (free of charge) and the company says thank you very much for the free labour. Company puts that software into everything it does, and pushes it into the infrastructure of everything it does. Some machines run that software because an…

> This is what happened e.g. with chrome. There's chromium, anyone can build it. But that's not chrome. And chrome is what everybody uses because google has lock-in power.

Because Google has their attention. You can use chromium, but most people don't and pick the first thing they see. Also, Chrome is a much better name, err, not better but easier to say.

> Then google says "oh I'm going to disallow you running the extensions you like, so we can show you more ads". Then they make tweaks to chrome so that websites only get rendered well if they use certain APIs, so now competitors to Chrome are forced to implement those APIs, but those aren't public.

You and I have a different definition of "forced". But, are you speculating this might happen, or do you have an example of it happening?

> And all of this was initially build by free labour, which google took, by people who thought they were contributing to some commons in a sense.

Do you have an example of a site that works better in chrome, than it does in chromium? I'll even take an example of a site that works worse in the version of chromium before manifest v2 was disabled, compared to whatever version of chrome you choose?

> Copyleft licenses protect against this. Part of the license says: if you use these licenses, and you make changes to the software, you have to share the changes as well, you can't keep them for yourself".

Is chromium not still foss? Other than branding, what APIs or features are missing from the FOSS version? You mentioned manifest v3, but I'm using firefox because of it, so I don't find that argument too compelling. I don't think FOSS is worse, I think google is making a bad bet.

Re: Gpg.fail

#179

Post by akerl_ » Sun, Dec 28, 2025, 5:18 AM UTC

Avamander wrote: post #175

akerl_ wrote: post #70

Earlier quoted context omitted.

> The disk is fully encrypted, and applications should be isolated from one another. For most apps on non-mobile devices, there isn't filesystem isolation between apps. Disk/device-level encryption solves for a totally different threat model; Apple/Microsoft/Google all ship encrypted storage for secrets (Keychain, Credential Manager, etc), because restricting key material access within the OS has merit. > I'm sure th…

> For most apps on non-mobile devices, there isn't filesystem isolation between apps. If there isn't there should be. At least my Flatpaks are isolated from each other. > Apple/Microsoft/Google all ship encrypted storage for secrets (Keychain, Credential Manager, etc), because restricting key material access within the OS has merit. The Linux equivalents are suspicious and stuck in the past to say the least. Dependin…

> Then we know where this stuff came from.

I can’t figure out what you mean by this.

Re: Gpg.fail

#180

Post by LexiMax » Sun, Dec 28, 2025, 5:32 AM UTC

ekjhgkejhgk wrote: post #148

Is anyone else worried that a lot of people coming from the Rust world contribute to free software and mindlessly slap on it MIT license because it's "the default license"? (Yes, I've had someone say this to me, no joke) GnuPG for all its flaws has a copyleft license (GPL3) making it difficult to "embrace extend extinguish". If you replace it with a project that becomes more successful but has a less protective (for…

I find that this is something reflective of most modern language ecosystems, not just Rust. I actually first started noticing the pervasiveness of MIT on npm.

For me, I am of two minds. On one hand, the fact that billion-dollar empires are built on top of what is essentially unpaid volunteer work does rankle and makes me much more appreciative of copyleft.

On the other hand, most of my hobbyist programming work has continued to be released under some form of permissive license, and this is more of a reality of the fact that I work in ecosystems where use of the GPL isn't merely inconvenient, but legally impossible, and the pragmatism of permissive licenses win out.

I do wish that weak copyleft like the Mozilla Public License had caught on as a sort of middle ground, but it seems like those licenses are rare enough to where their use would invite as much scrutiny as the GPL, even if it was technically allowed. Perhaps the FSF could have advocated more strongly for weak copyleft in area where GPL was legally barred, but I suppose they were too busy not closing the network hole in the GPLv3 to bother.