hey folks--
[ This message won't make sense unless the reader distinguishes clearly
between OpenPGP the protocol and GnuPG the implementation! As a
community we have a history of fuzzily conflating the two terms, which
is one of the reasons that we're in this mess today. Please read
explicitly. ]
[ Background: for those who don't know, i've been a maintainer in debian
of GnuPG and other OpenPGP-related tooling for several years, and i'm
also the co-chair of the IETF's OpenPGP working group; i participated
in many of the discussions that led to the current sorry situation,
and it is happening despite my best efforts to avoid this problem.
I'm probably as responsible for this situation as anyone in Debian
is. My apologies. ]
The best outcome, in my opinion, would be for GnuPG to go ahead and
implement the pending updated OpenPGP specification (the so-called
"crypto-refresh"). I say this despite personally preferring some of the
concrete ways that i think the GnuPG project would have preferred to (as
indicated by the latest "LibrePGP" Internet-Draft, at least) diverge
from the OpenPGP specification. There are enough other advantages to
the OpenPGP crypto-refresh that it doesn't make sense for GnuPG to
deliberately avoid implementing the community consensus. The GnuPG
project clearly has all the underlying cryptographic and engineering
capability to do this, if it wants to, and the OpenPGP crypto-refresh
process took deliberate measures to avoid collisions with any
prematurely deployed code that implements a draft that hadn't managed to
reach a rough consensus.
Can debian make GnuPG interoperate with the rest of the OpenPGP
ecosystem? Probably not without GnuPG's cooperation: it would be a
substantial patchset to carry in Debian, and even trickier to do if
GnuPG upstream sees such a patchset as hostile.
Read on below if you want to consider some other options.
Stephan Verbücheln wrote:
> As you probably know, Debian relies heavily on GnuPG for various
> purposes, including:
> - developer communication
> - signing of tarballs and patches
> - automated processes such as update validation by APT
Debian by policy and by mechanism relies heavily on the OpenPGP protocol
for these things. And i'd also add certificate verification, aka "web
of trust" for Debian developer identities to the list as well.
In particular, we use OpenPGP for cryptographic signing of software
source, packaging information, archive control, and distribution
mechanisms; for developer identities; and for cryptographic verification
of all of these things. As a project, we don't make much use of the
encryption/decryption parts of OpenPGP, since we develop mainly in the
open. But not everyone uses GnuPG for these purposes. There are
multiple interoperable OpenPGP implementations in Debian beyond the
GnuPG family (C), including RNP (C/C++), pgpainless (java), pgpy
(Python), GOpenPGP (Go), hOpenPGP (haskell), and Sequoia (Rust).
But it is also true that the GnuPG implementation specifically is baked
into some of our infrastructure. I'll get into why that is below (see
"Why is GnuPG on Debian's Critical Path?").
> How can Debian deal with this? Should Debian intervene to prevent the
> worst?
I don't think Debian can make a specific intervention that will avoid
the global problem, but i think there are things we can consider going
forward.
One possible approach is to drop the use of OpenPGP (or "LibrePGP")
entirely, and instead base our internal cryptographic dependencies on
bespoke cryptographic implementations.
I think that would be a mistake.
I do not want Debian's long-term health to depend on any particular
implementation. If the implementation fails then we would have to (as a
project) decide on our own upgrade path. For a failure due to
cryptanalytic advances, that can be particularly harrowing: I don't
think we as a project have the necessary expertise to do that well. For
failures due to buggy implementations, we can always patch, but i wonder
about the amount of cryptanalytic review a bespoke implementation will
have as opposed to publicly audited generic tooling.
If we have to decide as a project on LibrePGP vs. OpenPGP, i'd prefer
the wider community project with a stable reference, functioning (albeit
sometimes rough) consensus, a range of diverse implementations, and
substantial public interoperability testing. That means OpenPGP.
To be clear, the IETF OpenPGP working group actively solicited input
from the GnuPG team, and tried to work with the project as one
significant implementation among many. But ultimately, the GnuPG
project decided to break away from the community process, and created
this "LibrePGP" split, which threatens interoperability for the *PGP
ecosystem as a whole. Maybe the end result of this will be to put a
nail in *PGP's coffin, and we'll all just go back to bespoke
cryptographic implementations that have no stable reference other than
the source code, and little inte
