Sune Vuorela <
nospam@vuorela.dk> wrote:
Not only that, but some of these people were also in the
standardization workgroup knowingly forcing the schism by wanting,
what GnuPG upstream describes as, 'useless complexity' (my wording,
not theirs).
Hi there! In addition to having helped maintain GnuPG in Debian for
over a decade now, i'm also interested in there being a healthy OpenPGP ecosystem. I've also been partially responsible for packaging or
nudging other people to package several other OpenPGP implementations
being available in Debian (e.g. librnp, sequoia, rpgp, gopenpgp, pgpy, pgpainless). And, I'm also the co-chair of the IETF OpenPGP working
group, which i think is what you're referring to.
And i'm still helping to maintain GnuPG in Debian, despite this mess.
The idea that the other members of the working group were "forcing the
schism" doesn't line up with my experience. Werner decided to step away
from the process of standardizing something in an open and interoperable
way.
g10code (the builders of GnuPG) is, as far as i can tell, the driving
force behind the standards fork they've named "LibrePGP", whose motto
includes "Never Mind OpenPGP". Is this really the OpenPGP
implementation we want Debian to depend on?
Even when Werner was in control of the revision of the OpenPGP standard
(before he left the WG, he was the editor for the standard), his
proposals were in flux and people attempting to align with his published
code ran into problems aligning it with the published spec. Here's one
example from a few years ago, from an OpenPGP implementation that was
trying to follow along with Werner's plans:
the AEAD encrypted packet varies between the current implementation in
GnuPG (in use) and the latest version of the OpenPGP standard (more specifically the version field of the AEAD encrypted packet in the
standard is with value 2, and the standard proposes a fixed IV (initialization vector) for the AEAD packet in contrast with the algorithm-specific length at use by GnuPG at the moment and version 1
of the AEAD packet).
https://didisoft.com/2022/07/01/aead-cipher-support-in-openpgp/
When the WG was inactive (even farther in the past), GnuPG led the way
to using modern elliptic curve cryptography (e.g. with curve 25519), but
in doing so, it failed to specify what it was doing and how the objects
should be structured on the wire, which made it notably harder for other implementations to interoperate. The new standard is complex in part
because it *has* to accomodate those arbitrary choices made by GnuPG in
the past, which were not made with community review or input.
GnuPG continues to make these kinds of changes, which fail to
interoperate correctly not only other OpenPGP implementations but in
many cases with older versions of GnuPG itself.
These are all good arguments for specifying things in public, and giving
room and time for discussion, and making sure that implementations can
consume things (or at least fail safely/gracefully) before we emit them.
We don't want to be stuck with a single reference implementation as "the standard", because everyone makes some mistakes. I already linked in
this thread to concrete cryptographic concerns raised by non-GnuPG
participants in the WG that GnuPG has decided to ignore.
There are participants from a half-dozen OpenPGP implementations in the
working group, and most of them are interoperating with each other just
fine, even in cases where they don't get exactly what they would have
wanted from the standardization process. Yes, the process is messy, and
can be frustrating. And while there are parts of the
community-developed standard that are more complex than what Werner
wants most recently (e.g. more than one AEAD mode), there are also parts
that are significantly *simpler* than what Werner is advocating (e.g. no attempt to sign the Literal Data Packet's metadata misfeatures, adoption
of simple key and signature wireformats, explicit bindings between
session key formats and encryption formats, simplified message packet
grammar).
But the schism is, as far as i can tell, a disaster for both OpenPGP and
for the GnuPG project. The best outcome would be for GnuPG to be able
to parse the updated OpenPGP standards (keys, certificates, signatures, encryption), and to limit itself to emitting data that can also be read
by other implementations, including the new simplified formats. I know
that the GnuPG project has the cryptographic and software development
expertise to do it, but the project doesn't seem to have interest in
broad interoperability or demonstrating leadership within a pool of
peers, and is instead imposing this schism on the larger ecosystem.
Finally, engineering choices made by GnuPG have made it significantly
harder to upgrade even GnuPG itself, and slowed progress on other free
software work. To cite just two examples in the last year:
https://bugs.launchpad.net/launchpad/+bug/1827369
https://lists.debian.org/debian-devel/2025/01/msg00162.html
You can see other examples reflected in the patch history for GnuPG in
debian, where some engineering choices that make the tooling work better
are simply ignored by upstream despite pretty clear evidence that these
changes are valid for important use cases and don't break anything else.
These engineering choices make me wary of further cementing our
dependence on GnuPG in debian, and make me appreciate the process of collaborating with other downstreams of GnuPG to address broader
concerns.
In short, I'm a long-time supporter of the kinds of cryptographic work
that GnuPG has done. I want to see functional, interoperable
object-based cryptographic security tools in the hands of as many people
as possible, without vendor lock-in. Our users, the free software
ecosystem, and the cryptographic standards base is not well served by
GnuPG being the only OpenPGP game in town, or by distributing unpatched upstream GnuPG.
--dkg, more than a little depressed by this situation
--=-=-Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
wr0EARYKAG8FgmeFZScJEHctFh41zUuBRxQAAAAAAB4AIHNhbHRAbm90YXRpb25z LnNlcXVvaWEtcGdwLm9yZ4e63jIhW6Ba2DKXZZs49Njhlgk03yK5l0o6lfNhLcu+ FiEEdLwExD2GCEvoZywGdy0WHjXNS4EAAHU2AP0SLpb+HsW2CyAuFDbGzX1q8JkG V4e0rYIz4lc73MHmlQEAklR27Rf/YA9jqlP5fxcUy64xQf3B0ZLNjFWxzsnGcwMyW0
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)