GnuPG strength comparison ed448 vs ed25519 fixed (since 2024-11-25)

Posted Apr 21, 2025 23:12 UTC (Mon) by dkg (subscriber, #55359)
In reply to: GnuPG strength comparison ed448 vs ed25519 fixed (since 2024-11-25) by ber
Parent article: What's new in APT 3.0

The article already mentions the concerns that GnuPG is abandoning the OpenPGP standard. To my mind, that's a pretty serious quality issue (no scare quotes needed), because as soon as there's a major repository signed with modern OpenPGP signatures (i.e. using the definitions in RFC 9580), then depending on gpgv means signature validation failure. sqv (and at least two other OpenPGP implementations ready for debian trixie) already support the newer OpenPGP standards.

For the signature verification that apt is doing, gpgv also has a particularly unwieldy interface -- you can't just supply it with a signing keyring and a signed repository manifest (either InRelease on its own, or Release + Release.gpg) and check the return code to see whether the signature is valid. Instead, you have to ask gpgv for the "status file descriptor" (via --status-fd) and build a state machine to parse and reason about its output.

If you (or anyone) is interested in other quality issues that GnuPG upstream is declining to fix, you might also want to look through the fixes proposed in the FreePG project. I also encourage people with a C programming background to look at the codebase, which suffers from a lack of testing compared to the size of the interface it presents, and carries significant unresolved technical debt.

(disclaimer: i'm a co-chair of the OpenPGP working group in the IETF; one of the debian maintainers for GnuPG itself; a contributor to the FreePG project; the author of a wrapper around gpgv to make it conform to standardized signature verification semantics; a long-time contributor to GnuPG; and a sad observer of that project's apparently deliberate slide toward irrelevance for the free software ecosystem)