Re: PGP and GnuPG specifications
Vincent Breitmoser via Gnupg-users <[email protected]> Fri, 8 May 2026 09:59:18 +0200
| Newsgroups | gmane.comp.encryption.gpg.user |
|---|---|
| Message-ID | <[email protected]> |
Hey list, On 5/8/26 04:29, Robert J. Hansen via Gnupg-users wrote: > LibrePGP is effectively RFC4880-bis-10, I think, dating from July 2016 > or so. RFC4880 was published in 2007, so Werner had been extending the > spec *and fully cooperating with the process* for nine years. > > Over those nine years GnuPG picked up a lot of users and became the most > commonly used RFC4880 and RFC4880bis implementation out there. > > A few years ago there came a point where the WG needed to decide whether > to say "RFC4880-bis-10 is going to be the end of our experiments, this > is going to be the long-term release going forward", or ... something else. While I think your description is largely fair, I'll add that the timeline of conflict is more compressed and less linear than what you describe: * rfc4880bis-00 was published in November 2015. It contained basically no original content, but only merged errata and RFCs like ECC and the Camellia cipher. * The v5 format was first added to the spec in March 2017, published as -02 in June 2017. * In the following three years, there was lots of disagreement in the working group. If memory serves, the hot debate was actually more centered around AEAD than what a v5 packet format would look like. * Things came to a head in 2020. I wrote an email to the list that ultimately triggered the schism, but this was not a momentary event. The writing had been on the wall for a long time at that point. * Werner released rfc4880bis-10 in August 2020 (not July 2016 as you stated), before leaving his position as editor. * Support for v5 was released in [GnuPG 2.3.0] (2021-04-07), and released in a stable version as GnuPG 2.4.0 (2022-12-16). Obviously none of this is black-and-white. And you're right, GnuPG was in a first-mover position in several things and tried to follow process for a long time. But I will also say that GnuPG's current position as an incompatible implementation is at least partially caused by an intentional bet to leverage its de-facto weight in ~2021-2022, hoping everyone would follow suit, that backfired when everyone didn't. - V [GnuPG 2.3.0]: https://dev.gnupg.org/source/gnupg/browse/master/NEWS$1666