[pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

Tue Aug 15 00:00:11 BST 2023

Hi all--

Many apologies for the delayed response on this thread, and my recent
delays on GnuPG in debian generally.  My time has been lacking here, and
my relationship with GnuPG upsteam is sadly strained, though i wish it
were not.

I really appreciate the work that other folks have put in here to think
through next steps, and i don't want to stand in anyone's way.  I've
always tried to do my work on GnuPG in debian within a team context, and
with my strong belief in LowNMU as well, i'm not interested in being a
blocker.

I have some concerns about the suitability of newer versions of GnuPG
for decent system integration on current GNU/Linux systems, and for
OpenPGP ecosystem interoperability, which have led me to shy away from
deliberately packaging the 2.4.x series directly for Debian; i don't
know how to resolve those concerns.  But that doesn't mean that other
people who are eager to tackle these problems shouldn't work on it.
And, to the extent that i have time to offer review, i'd be happy to
weigh in.  But i don't want anyone with the capability and interest to
do this work to be waiting on me.

The libgpg-error packaging Andreas as produced for experimental looks to
me like it should probably be uploaded to unstable directly, as that's
useful work regardless of what version of GnuPG is in the archive.
Thank you, Andreas!  Thank you also to gniibe for his work toward
improving smartcard accessibility!

How we move ahead with newer versions of the gnupg2 and gpgme1.0 source
packages might be a bit trickier, but i trust the good people on this
thread to think through those concerns.

Below, i describe some of my concerns around the 2.4.x series that have
kept me from figuring out how to do useful work here, but none of them
should be taken as blocking objections.  They're just background for
folks who are considering this packaging work.  Some of these concerns
resonate for me even with the 2.2.x series as well, but i think they're
heightened in the 2.4.x series. It's also possible that i'm wrong about
any of these details, and i welcome any corrections.

 - GnuPG's use of long-running daemons has a complicated history.  I
   generally like the idea of long-running services that can share load
   between and isolate risk across multiple running processes.  But the
   reality of the integration is that it just hasn't practically worked
   well for this project.

   Upstream's standard approach for launching necessary daemons is
   associated with a history of race conditions
   (https://bugs.debian.org/868550), unnecessary delays
   (https://dev.gnupg.org/T3490), excess power consumption
   (https://dev.gnupg.org/T1805), configuration/state confusion
   (https://dev.gnupg.org/T4513) and failure to shutdown/cleanup
   correctly at logout (https://dev.gnupg.org/T2858).

   Some of these problems were mitigated on debian (at least for the
   standard GnuPG homedir) by the use of systemd user services with
   socket activation, much of which was adopted upstream.  Debian has
   also for years carried additional patches that i tried to forward
   into upstream to improve some of the problems above
   (e.g. https://lists.gnupg.org/pipermail/gnupg-devel/2016-November/032011.html)
   but they haven't landed and they are increasingly difficult to
   maintain.

   In the 2.2 series, GnuPG relied on long-running daemons for secret
   key access (gpg-agent), smartcard access (scdaemon), and network
   access (dirmngr).

   In the 2.4 series, GnuPG uses all of the above and additionally
   depends on a long-running daemon for public key access (keyboxd).

   Furthermore, in the 2.4 series, i understand that the systemd
   integration has been removed, which means that many of the potential
   problems with upstream's approach for daemon-handling are likely to
   recur.

   I hope a responsible packager for debian will think about how to
   address these system integration issues, even if they are not
   personally affected by them (e.g. if you run GnuPG as a single user,
   never doing parallel invocations of GnuPG, on a desktop computer with
   a stable network connection and no worries about power consumption,
   and you hardly ever log out of the system).  If we want this tooling
   to work for normal users who might vary from any of the above
   conditions, then we need some more plausible, usable answers than
   "just remember to run 'gpgconf --killall $DAEMON_NAME' when you log
   out/change networks/switch to battery power/etc".

   Werner mentioned some of these concerns on this thread already, and
   objected to service management on the grounds that it should work the
   same way on all platforms.  But that's not how i imagine system
   integration to work.  On systems that manage services in a specific
   way, quality system integration should make each project-specific
   service work the way the system generally works.  This is surely a
   burden of cross-platform maintenance, but it comes with the
   territory.

 - GnuPG's 2.4.x series encourages the use of a variant of the OpenPGP
   wire format that was developed without reaching consensus of the
   broader OpenPGP community.  There are a handful of specific technical
   problems with these formats (e.g. GnuPG's proposed "version 5
   signatures" can be aliased into v3 signatures over a subtly different
   bytestream, https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/130,
   and its form of encrypted data risks having session key reuse across
   different algorithms
   https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/101), but
   more generally the past failure to reach consensus among the
   half-dozen OpenPGP projects that were participating in the revision
   process that petered out on GnuPG's implementation suggests a
   potential ecosystem fragmentation.  As a co-chair of the OpenPGP
   working group at the IETF, i have to own that failure to reach
   consensus at least as much as anyone else.  But in the last year, the
   same WG has reached a rough consensus reached that resolves these
   issues, and it's not clear that GnuPG will implement it (though i
   certainly hope the project will).  I believe all the building blocks
   are in place within GnuPG 2.4 and gcrypt to implement the newer wire
   formats (SEIPDv2 and v6 keys+sigs), so GnuPG could advance the state
   of the field as it has in the past.  However, if GnuPG upstream
   declines to do that implementation, and as v6 keys+sigs and SEIPDv2
   messages become more widely available, any debian maintainer of GnuPG
   will face pressures from users to either patch GnuPG to handle the
   new formats or to push those changes upstream.

   I wish i was confident enough in my relationship with the GnuPG
   project to be able to shepherd those changes upstream *and* in
   Debian, but my failure to get even relatively simple changes
   upstreamed that reduce, say, daemon power consumption doesn't suggest
   that i'm well equipped to do that.  When it comes to protocol wire
   format issues, i haven't even been able to convince GnuPG upstream
   for years to accept commonplace sensible indicators of revocation
   (e.g. pubkey packet + revocation packet) as witnessed by
   debian/patches/import-merge-without-userid/*.patch and, e.g.
   https://dev.gnupg.org/T4393 .  Werner also mentioned this upthread
   and i respectfully disagree with him here.  This is not about choice
   of keyserver network (though it does touch on that), but about users
   being able to identify revoked keys when presented with
   cryptographically compelling evidence of revocation.

   In summary, I don't know how to convince upstream that these
   wireformat issues warrant adoption by GnuPG, and i don't know how to
   resolve the inevitable tensions we'll face within Debian as user
   demand for these features increases.

At any rate, i welcome other maintainers to work on the project of
keeping GnuPG well-integrated with debian, and to the extent that i have
time/capacity to help (and particularly where i won't cause additional
hindrance) i would be happy to pitch in.

GnuPG is an important piece of our free software infrastructure, and it
needs the attention folks here seem poised to give it.  I hope i can be
helpful going forward, and i do not at all resent any attempts to
address these larger issues.

All the best,

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20230814/6e1071b5/attachment-0001.sig>