On Sat 2025-01-04 11:46:00 +0200, Martin-Éric Racine wrote: > I really don't have any opinion on which GPG implementation should get > selected. My key point is to pick one and apply it across the board > for dpkg, apt and devscripts. Until recently, it meant gpg/gpgv across > the board. I also don't mind if software includes support for various > implementations. My goal here is to avoid dependencies being all over > the place. If the consensus if for sop/sopv, I'm fine with it. If it's > for sq/sqv, I'm fine with it. I simply want to avoid an outcome where > each of those key packages has a hard Depends on an entirely different > GPG implementation.
I think i understand your goal, but i also think you're confusing the
data formats exchanged -- OpenPGP objects -- with the implementation
used to generate and process those objects. Full disclosure: i'm a
co-chair of the OpenPGP working group within the IETF, so i'm perhaps
more tuned in to the distinction between data format and implementation
than most people.
Unlike in the past, we have more OpenPGP implementations available today
than GnuPG, and each implementation offers different affordances and
capabilities. For interoperability testing, most implementations do
support a minimalist common interface, the so-called "stateless openpgp
CLI", or "sop", which i've been stewarding. To the extent that those
implementations implement sop, they are effectively interchangeable.
Apt has a set of very specific goals for its handling of OpenPGP
material, so it selected a specific tool that it wants to use for those
features.
dpkg and devscripts have a different set of needs, and they accordingly
might select different tools. We don't say that our developer tooling
must all use OpenSSL for TLS connections, and we don't say that our
developers must all use vim for text editing, perl for data parsing, or
write their code in C++. If we allow for diversity in those areas, why
should developer tooling be obliged to pick an OpenPGP implementation on
the basis of what any other tooling picks?
Having a diverse and active set of OpenPGP implementations is a healthy
thing for the free software ecosystem. Forcing consolidation into one
implementation puts the data format itself at risk (as we have seen from
GnuPG upstream's recent move away from supporting the OpenPGP standard),
and, more importantly, it puts Debian at risk should that implementation
become unsupported or unsupportable.
--dkg
signature.asc
Description: PGP signature
