[flagged]
Gpg.fail
41–50 of 376 posts
Re: Gpg.fail
#42AFAICT this is GnuPG specific and not OpenPGP related? Since GnuPG has pulled out of standards compliance anyway there are many better options. Sequoia chameleon even has drop in tooling for most workflows.
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
Since when are age or minisign PGP implementations?
Re: Gpg.fail
#43This 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…
> Surely IBM & co have a couple of spare developers or spare cash to contribute?
A major part of the problem is that GPG’s issues aren’t cash or developer time. It’s fundamentally a bad design for cryptographic usage. It’s so busy trying to be a generic Swiss Army knife for every possible user or use case that it’s basically made of developer and user footguns.
The way you secure this is by moving to alternative, purpose-built tools. Signal/WhatsApp for messaging, age for file encryption, minisign for signatures, etc.
Re: Gpg.fail
#44Okay, since there’s so much stuff to digest here and apparently there are issues designated as wontfix by GnuPG maintainers, can someone more in the loop tell us whether using gpg signatures on git commits/tags is vulnerable? And is there any better alternative going forward? Like is signing with SSH keys considered more secure now? I certainly want to get rid of gpg from my life if I can, but I also need to make sur…
These are not vulnerabilities in the "remote exploit" sense. They should be taken seriously, you should be careful not to run local software on untrusted data, and GPG should probably do more to protect users from shooting themselves in the foot, but the worst thing you could do is panic and throw out a process your partners and colleagues trust. There is nothing here that will disturb your workflow signing commits o…
A huge part of GPG’s purported use case is getting a signed/encrypted/both blob from somebody and using GPG to confirm it’s authentic. This is true for packages you download and for commits with signatures.
Handling untrusted input is core to that.
Re: Gpg.fail
#45Werner Koch from GnuPG recently (2025-12-26) posted this on their blog: https://www.gnupg.org/blog/20251226-cleartext-signatures.htm... Archive link: https://web.archive.org/web/20251227174414/https://www.gnupg...
[flagged]
i wouldn't normally reply to drive-by corrections, but this is wrong.
it's the GnuPG blog on gnupg.org with multiple authors.
this is a post by Werner Koch, not his blog.
Re: Gpg.fail
#46Earlier quoted context omitted.
GPG is indeed deprecated. Most people have never heard of it and never used it.
Can you provide a source this? To my understanding, the GnuPG project (and by extension PGP as an ecosystem) considers itself very much alive, even though practically speaking it’s effectively moribund and irrelevant. (So I agree that it’s de facto dead, but that’s not the same thing as formal deprecation. The latter is what you do explicitly to responsibly move people away from something that’s not suitable for use…
Ah. I meant in the de facto sense.
Re: Gpg.fail
#47Zero-days from the CCC talk https://fahrplan.events.ccc.de/congress/2025/fahrplan/event/... But trust in Werner Koch is gone. Wontfix??
To be frank, at this point, GPG has been a lost cause for basically decades. People who are serious about security use newer, better tools that replace GPG. But keep in mind, there’s no “one ring to rule them all”.
What are those better tools? I've been broadly looking into this space, but never ventured too deep.
Re: Gpg.fail
#48Earlier quoted context omitted.
These are not vulnerabilities in the "remote exploit" sense. They should be taken seriously, you should be careful not to run local software on untrusted data, and GPG should probably do more to protect users from shooting themselves in the foot, but the worst thing you could do is panic and throw out a process your partners and colleagues trust. There is nothing here that will disturb your workflow signing commits o…
A huge part of GPG’s purported use case is getting a signed/encrypted/both blob from somebody and using GPG to confirm it’s authentic. This is true for packages you download and for commits with signatures. Handling untrusted input is core to that.
It is, and other software handling untrusted data should also treat it as adversarial. For example, your package tool should probably not output raw package metadata to the terminal.
Re: Gpg.fail
#49Earlier quoted context omitted.
To be frank, at this point, GPG has been a lost cause for basically decades. People who are serious about security use newer, better tools that replace GPG. But keep in mind, there’s no “one ring to rule them all”.
What are those better tools? I've been broadly looking into this space, but never ventured too deep.
Sequoia for example has been doing a great job and implements the latest version of the standard which brings a lot of cryptography up to date
Re: Gpg.fail
#50[dead]