However, one thing is a specification and the other thing is running code.
Wait a minute, are you saying that running code comes first, and specs are meant to play catch up? At the beginning of the standardisation process that makes a ton of sense, but once the standard is established, it should take precedence.
Now in 2026, the onus is on GnuPG to follow OpenPGP, the same way GCC is complying to the C and C++ standards.
p.s. I did not like to coin the term LibrePGP because actually GnuPG was the software which consistently talked about OpenPGP and not about PGP or GPG when talking about the protocol.
Promoting the standard instead of your particular implementation is commendable. On the flip side, doing so strongly implies a promise to follow those specs going forward.
But eventually I came up with LibrePGP to help avoiding confusion about what new protocol variant we are talking about.
Had GnuPG kept its implied promise to follow OpenPGP, there would be no confusion. Other problems perhaps, but no confusion.
To most people outside the GnuPG project, it's crystal clear OpenPGP is the mainline. Most haven't even heard of LibrePGP. Of course they're confused when they find GnuPG has stopped complying with OpenPGP (if it ever has).
In fact, I'm pretty sure the most effective way to end the confusion is to deprecate LibrePGP and start complying with OpenPGP again. It may be a ton of work of course (I've heard GnuPG's code base is old and may be hard to change), but it would end the confusion.
Loup. _______________________________________________ Gnupg-users mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-users
