Hey, Werner. On 7 May 2026, at 10:26, Werner Koch via Gnupg-users <[email protected]> wrote: > > However, one thing is a specification and the other thing is running > code. The running code in 1997 was PGP 5 and GnuPG followed the > development and peculiarities of that implementation closely. There has > been a good understanding between the folks actually writing the code on > how to do things which have not been fully specified of where an one > implementation derived from the RFC.
That’s fair when you are taking a once-proprietary protocol and adopting it as an open one. Backwards compat with the install base is crucial of course, and bug-for-bug compatibility is a necessary evil at the beginning of a standardisation process. Where we disagree is how to manage the open standard afterwards. I don’t think we should just replace PGP with GnuPG and carry on in the same manner with the names changed. A healthy ecosystem needs a broad spectrum of input, not just hand-picked people in a private chat. We need experimental code with open discussion and public interop testing before shipping anything in production. That doesn’t mean that private chats have no place in the process, or that we need to pay equal attention to everyone’s half-baked ideas. But gnupg has swung too far in the opposite direction. Take draft-koch-librepgp-05: there are three new “reserved code points” in the tables. What are they for? Where are the design docs? Public key algorithm code point 29 is burned because gnupg shipped experimental PQC code that used it - and then moved to code point 8 instead. We have a private and experimental area for this, why was it not used? Curve 448 wire representations had their prefix octets removed without any discussion or notice. There’s a truncated “25-octet v5 fingerprint” that appears sometimes if you use a particular combination of CLI flags, and you can create “v5” fingerprints over v4 keys and/or “v4” fps over v5 (I’ve lost track). These are not bugs; they are deliberate choices made without regard for other implementors. How is anyone expected to interoperate with this? A _______________________________________________ Gnupg-users mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-users
