• What do we do about GnuPG 1.4 in debian?

    From Daniel Kahn Gillmor@21:1/5 to All on Fri Apr 29 23:50:01 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

    -----BEGIN PGP SIGNATURE-----

    iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYmxZpAAKCRA+nXFzcd5W XJTUAQC1c7bCUglXefn2TGEI8dFZcPiQvDfGYU/ZlKIkrUooCQEAy5oJT2VYL+lp 4faQ3dRud1EbmgXfLuY53hJmR5KdCgc=
    =owej
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Paul Wise on Sat Apr 30 02:10:01 2022
    Paul Wise <pabs@debian.org> writes:
    On Fri, 2022-04-29 at 17:33 -0400, Daniel Kahn Gillmor wrote:

    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.

    Are there any things that can be done with GnuPG 1.4 that cannot be
    done with GnuPG 2 or one of the other OpenPGP implementations?
    For example decrypting files using old OpenPGP keys.

    Yes, verifying signatures using obsolete keys or obsolete algorithms which
    are no longer supported in GnuPG 2. One can, of course, debate the merits
    of the continued existence of such signatures, but they're still
    relatively common for managed Usenet hierarchies because a lot of Usenet
    is now running on autopilot (although we're slowly pushing people to modernize).

    For example, running import on the list of currently known keys for Usenet hierarchies (many of which are admittedly dormant) says:

    gpg: Total number processed: 101
    gpg: skipped PGP-2 keys: 84
    gpg: unchanged: 17

    (I'm not intending this to be an argument for keeping GnuPG 1.x. The
    forcing factor of Debian dropping support for the old keys may even be
    useful. But it may be helpful for judging the impact.)

    --
    Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to Daniel Kahn Gillmor on Sat Apr 30 02:00:01 2022
    On Fri, 2022-04-29 at 17:33 -0400, Daniel Kahn Gillmor wrote:

    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.

    Are there any things that can be done with GnuPG 1.4 that cannot be
    done with GnuPG 2 or one of the other OpenPGP implementations?
    For example decrypting files using old OpenPGP keys.

    --
    bye,
    pabs

    https://wiki.debian.org/PaulWise

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmJseZ8ACgkQMRa6Xp/6 aaPrZA/+NSIkIUWnYEvjTmC4MknH86ZS5R/13JpYAY0c1WQI+xNp7R97gQ8MRJ3r soeVq0gRoHEsoi3W/X1U2NR257FSjsp0eTKE6MAyChy95l+o+akTv+bLTejmI+Dq 1+9FHOJhnzsmmrCO3++zdnetHKiCfpW99FSA5omPEtoZrZ/EnFhsq0ra/5iLAFGe xcCFhc8QPb4HkEEV4GaLDBKRMXjnkZg642OuxY+VPlRI8/KCc881KI4W2wH3BPhL mmWt/WZrdJZvSYAU3C08zh/a25iL7rI9M6jKwH4TCffa0tD/qXS+lh8TYFmr5XRe x63mNI5NS1PxSbOuFS6KXFLIYItoUAmb2xyE/pQD8MpXbfmYmMTUanVghodmhExL woxpe/9eDm0V8Re5Ys0Mw5vtatmQ0IWDnnEbXIswqshxEy1ThTyPuUN9WfBRjwKo uXtQHSWE+AG9mrY7I71+2SgJcijXKldL9bOJ8+yDzP1zUOkNoEVijLXCHcqzk52e DZfGySrfQDo/3wcK4pxuNAlD0Opx7DXSY3lTgVe+YlunfOItNEqNZ33KRxAyMweR ZM2E7Lyb3ZKpNaCxQEhaHcTirF3S5ra89MOEOUxdkKHHGOEQ4cpiuT5DYmejjFwz PW7LeZifD7e8549Eal5EROWKkWQJTL/JgDw/sTFLARBp7reTMUY=
    =qKrs
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Paul Wise on Sat Apr 30 03:10:01 2022
    Paul Wise <pabs@debian.org> writes:
    On Fri, 2022-04-29 at 17:04 -0700, Russ Allbery wrote:

    Yes, verifying signatures using obsolete keys or obsolete algorithms
    which are no longer supported in GnuPG 2.

    and nothing other than GnuPG 1 supports these keys?

    I'm personally not aware of anything other than the even more obsolete commercial PGP implementations, but maybe the package maintainers know
    more.

    It seems like it would be a good idea for GnuPG 2 or other OpenPGP implementation to at least have an option to re-enable them
    temporarily.

    It would be nice, but my understanding is that this was a deliberate simplification by the GnuPG maintainers, which is why their official
    position has been that people who need such support should use GnuPG 1.
    I think the change that broke most of the keys was made in GnuPG 2.1.0:

    * gpg: All support for v3 (PGP 2) keys has been dropped. All
    signatures are now created as v4 signatures. v3 keys will be
    removed from the keyring.

    There are a few other problems that old keys or old signatures could have
    other than this one, but I think this is the most significant one.

    --
    Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to Russ Allbery on Sat Apr 30 02:30:01 2022
    On Fri, 2022-04-29 at 17:04 -0700, Russ Allbery wrote:

    Yes, verifying signatures using obsolete keys or obsolete algorithms
    which are no longer supported in GnuPG 2.

    and nothing other than GnuPG 1 supports these keys? It seems like it
    would be a good idea for GnuPG 2 or other OpenPGP implementation to at
    least have an option to re-enable them temporarily. In any case I
    suppose there is always snapshot.debian.org if someone needs GnuPG 1.

    --
    bye,
    pabs

    https://wiki.debian.org/PaulWise

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmJsgi0ACgkQMRa6Xp/6 aaOcdQ/9HXd0aBibKrM/xSWfC2bQtXIfhOuPPhofXcxX8HIYcIJFk91FIumFaCEj n+mCAG3YoMLgPLAhQ0DzSpsCqzIAgGx1hwmwuuurUx/yvHBpjvCXVihCt36Dd5uq 7eV0tvNBMKu50fzjl8Aab99yWqHua32XDJS57EkRiwVCuEHXuabxjTzU6im8rKzK 6zZycAU+HvCaHd627TM72mcJTOKDW9CUHATc72sFy+nw8sboaWP3P/9AF7z/f5pq XHY7C1juV4f1ZK8f+AmQlGQEAvweQeuCjUE6ODUcqTxnmD2kF2oS7T8LPSxsWcCl bQ4YBN7+znYIeZ0cG1AXAiYY1upzZDmAq5xwwKk7JbvZK/8Vs0kiWAD6XJ1GzWoR GodhAPnVu6sDXSb+MRnBPVPUxlDKQ9OPSRq/BAKPuv7CcJroiUfEA4WYVv8/FjI1 yMDpdDdXceWuGFpiVVszeXCnHhx2Bl61ZAk8v/enq+E/pCDuLu2JGTQkKawAtZxy HKiDLL3tTX+XKiMU3KqveZxMiRS93Kiyv8Bkep/4w5miczum5su5NksmcjYASMfq I6aarqC+Icp0xAxdQXyGi6EldByDAw0cHDiAa3EVoyPHUNHMR97Ydb+TzFe88ZRc SXAddSzyhM379dYR9bR4joVT9Px71WTTvgdEHqZq5G3IlbpXqAc=
    =2Im6
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)