GPG seems… weird?

https://floss.social/@hko/116459621169318785

> While GnuPG 2.5.x implements hybrid PQC encryption based on ML-KEM, […] GnuPG's implementation is entirely incompatible with the IETF-specified format, which all other libraries are implementing.

> Both serialization and the KEM combiners differ.

> The bottom line is that anyone who wants to use vendor-agnostic PQC with OpenPGP should avoid GnuPG's PQC key formats.

> This is all exceedingly unfortunate and weird, and frankly, a total disgrace.

> Also see https://chaos.social/@dvzrv/116460347482223544

> It would appear that GnuPG upstream is trying to use its influence to create facts on the ground (by proliferation of its proprietary non-OpenPGP formats).

https://floss.social/@hko/116464388341452694

> GnuPG's new, non-OpenPGP formats are "proprietary in the governance sense":

> One actor unilaterally decides what they want to do, while not meaningfully engaging with anyone else.

> Then they implement their preference, and write up some document that more or less describes the format.

https://mastodon.ie/@andrewg/116464341607363847

> GnuPG is not proprietary, of course. But the “librepgp” formats that it promotes as an alternative to OpenPGP are “proprietary” in the sense that they are the work of a single person, who happens to be the GnuPG project lead, and have been rushed into production against the advice of nearly every other openpgp implementer.

https://floss.social/@dvzrv@chaos.social/116460347519274876

> I'm getting quite annoyed with the state of #GnuPG as a packager.

> Upstream silently keeps releasing 2.2 versions to this day(!) and at the same time claims 2.4 will soon be EOL (also refuses to backport security fixes for it).

> Meanwhile, there are no good reasons to upgrade to 2.5, unless one wants incompatibility with the entire rest of the ecosystem (see https://wiki.archlinux.org/index.php?title=GnuPG&oldid=86021...).

> The move to #OpenPGP #RFC9580 compliant solutions can't happen early enough!

> Also, I'm glad we have @freepg

> Everything gets even more wild once you notice that upstream itself appears to flag the package out of date and is trying to upsell the new features.

> Apart from the incompatibility madness: Without the #FreePG patches, there no longer would be #systemd support (which we require!) in 2.5, because upstream removed it (what seems to me, out of spite).

https://mastodon.ie/@andrewg/116464399797066586

> many of us suspect that the root of the problem is the age of gnupg’s codebase, which bakes in a lot of assumptions and premature optimisations, and which doesn’t have any unit tests or continuous integration. It’s a codebase that few outsiders understand and which few insiders are confident about making major changes to.

I feel a bit uneasy about entrusting my security to that mess.

https://floss.social/@hko/116465281149794524

> The good thing is that no one is forced to deal with GnuPG's increasingly odd choices.

> My perspective is that there is really only one sensible path forward: The formats that are developed by the OpenPGP WG at the IETF.

> There are half a dozen independent implementations of both RFC 9580 and draft-ietf-openpgp-pqc.

> It's clear that there is a lot of consensus, and will to modernize in a collaborative fashion.

> This is of course complicated by GnuPG effectively attempting to derail these developments

> I don't think there is anything constructive left to do, in that regard. Many people have tried to build many bridges. To no avail.

> The only remaining option is to try and protect captive GnuPG user bases from the fallout, as much as possible. This is the goal of @freepg

> The GnuPG situation is not great. But I think the ecosystem is being as constructive as circumstances allow.

GnuPG – post-quantum crypto landing in mainline