[pkg-gnupg-maint] What do we do about GnuPG 1.4 in debian?

Daniel Kahn Gillmor dkg at fifthhorseman.net
Fri Apr 29 22:33:24 BST 2022


Hey Debian GnuPG folks (and QA team)--

The "classic" branch of GnuPG (aka "gnupg1") is increasingly untenable
for modern deployments.  This e-mail proposes to orphan the package and
potentially ask for its removal from the archive over the next half-year
or so, unless someone else (from within the debian GnuPG packaging team,
or outside of it) wants to take responsibility for the package.

Here is the outline of the high-level concerns I have:

 - GnuPG 1.4 lacks ECC support, and many modern keys are using elliptic
   curves.

 - GnuPG 1.4 has minimal upstream involvement.  According to
   https://versions.gnupg.org/swdb.lst the last release is 1.4.23, which
   was almost four years ago (2018-06-11).  in https://dev.gnupg.org/, i
   see that gniibe did some work on it upstream in 2021 to try to make
   it compile on RiscOS, but that has not been released.  Upstream git
   still defaults to using SHA1 for making signatures unless explicitly
   directed otherwise.  (we patch the SHA1 issue in debian, and
   apparently 1.4.23 does at least build in our riscv64 builder without
   gniibe's patches:
   https://buildd.debian.org/status/logs.php?pkg=gnupg1&arch=riscv64&suite=sid)

 - GnuPG 1.4 has difficulty dealing with secret keys that are shared
   with other devices (due to incompatibilities with how secret keys are
   stored), and using it on the same machine as a more modern GnuPG
   installation risks getting secret key and ownertrustdb storage out of
   sync in ~/.gnupg.

 - GnuPG 1.4 also fails many tests on the OpenPGP interoperability test
   suite (https://tests.sequoia-pgp.org/) which is in large part (but
   not only) due to the lack of ECC support.  I wouldn't consider
   failures in that interop test suite to be particularly troublesome if
   it looked like there was any hope of getting it fixed in the near
   term, but upstream's lack of attention to it, i can't help but worry.

 - Even our debian packaging is out of date (debhelper 11,
   standards-version 4.1.4).  We formally deprecated GnuPG 1 in debian
   in commit 5fd952a5cdc721a558562d87bd1d360229393d28, over five years
   ago.

In short, I think having GnuPG 1.4 in the debian archive much longer is
more likely to cause problems for debian users than it is to solve them.

Furthermore, as i consider the amount of time i personally have
available to devote to keeping GnuPG up-to-date, i have to admit i'm not
giving it the attention it deserves, and Christoph Beidl is the only
person who has stepped up in the last several years to keep it building.

If anyone wants to take responsibility for gnupg1, please speak up.  If
you're in the GnuPG packaging team and you want to keep it under the
packaging team umbrella, that is fine with me.  Also fine if you want to
move it out from the packaging team umbrella to individual
maintainership.  If you want it, please say so.

If i don't hear a response offering to take responsibility for it in the
next month or two, I will probably do the following:

 - File a bug report in debian orphaning the package

 - File bug reports to every package that explicitly Depends,
   Recommends, or Suggests on gnupg1 asking them to drop those
   dependencies.

 - Ask the Debian QA team (in cc here) to consider whether they want to
   take it over.  If there is no interest from the QA team after a
   while, or if they recommend dropping it, i'll upgrade the orphaning
   bug report to an RM bug report.

I expect some people who who keep GnuPG 1.4 around for handling some
weird legacy archival data to be upset by this.  If there are specific
needs, perhaps we can find other ways that they can meet them safely.
Or, perhaps they want to adopt the package to keep it available for
their own use.

In the worst case, those folks can still pull the package from source,
or even try using binaries from old versions of debian.

Thanks for thinking this through with me,

   --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/20220429/ca60add2/attachment-0001.sig>


More information about the pkg-gnupg-maint mailing list