On Sun 2025-02-09 10:52:47 +0100, Emilio Pozuelo Monfort wrote:
> I agree with this sentiment, and with my Release Team hat on, I don't
> think we want to have three implementations in trixie. You should work
> with the maintainer to try and get it updated if possible, and
> otherwise maybe it can be uploaded to -backports post trixie release.

fwiw, Simon and i had a good conversation a little while ago about some
reasonable strategies going forward for GnuPG in debian.

I've spent the time since then looking at trying to make some changes in
the debian experimental packaging for 2.4, and 2.4.7-4 (in experimental
now) is the result of the first phase of that work.

(i tried submitting some of those changes upstream, but even the
beginning parts which i thought would be mostly unobjectionable were
either rejected or ignored upstream for reasons i can't say i fully
understand (https://dev.gnupg.org/T7511), so alas it means we'll be
carrying an even heavier patch load, sigh)

The NEWS file entry for 2.4.7-4 sums up the overall gist of the approach
i've taken:

------
gnupg2 (2.4.7-4) unstable; urgency=medium

  The upstream GnuPG project now explicitly and deliberately diverges from
  the OpenPGP standard.  Debian's own workflows rely heavily on OpenPGP,
  and we ship several different OpenPGP implementations, so
  interoperability via standardization is a priority for the project.

  While Debian still has significant dependencies on GnuPG, the version of
  GnuPG shipped in Debian will default to emitting only OpenPGP-compatible
  artifacts if at all possible.  As of 2.4.7-4, the default
  is --compliance=openpgp, and we apply several patches to ensure that
  this mode is respected.

  If you observe GnuPG in Debian emitting a non-OpenPGP artifact in a
  scenario where a standard OpenPGP artifact is intended or expected,
  please open a critical bug report in the Debian BTS.

  If you want Debian's GnuPG to emit non-standardized artifacts, in line
  with upstream's deliberate divergence, you can explicitly pass
  --compliance=gnupg (or set the corresponding option in
  ~/.gnupg/gpg.conf).  If you revert to compliance with upstream defaults,
  do not expect the material you produce to be interoperable with other
  OpenPGP implementations.

 -- Daniel Kahn Gillmor <d...@fifthhorseman.net>  Fri, 07 Feb 2025 23:35:29 
-0500
------

Simon, i don't know whether this approach would be acceptable to you or
not.

My preference would be for upstream to maintain a sensible
--compliance=openpgp mode, and then all that i think Simon and i would
disagree about would be whether debian changes the default compliance
mode in what we ship.  But apparently upstream doesn't even want to
accept patches that would create a realistic --compliance=openpgp mode,
so to the extent that we need OpenPGP interoperability in Debian we are
gonna need to carry some patches.

I'm also trying to coordinate those patches with other distros that have
similar concerns (e.g. Fedora and Arch) via the FreePG project so that
we're not entirely on our own:

   https://gitlab.com/freepg/gnupg/-/merge_requests/14

I'll also note that as i've been doing this work, i ended up opening
https://bugs.debian.org/1095515 (thanks Andreas for pointing me to the
relevant details and history which i'd either missed or forgotten); i'm
not sure the right way to resolve this, but it seems likely to break
some significant tooling in subtle ways if we move 2.4 from experimental
to unstable.

What do i mean by "subtle ways"?  I mean it won't break for everyone,
only for people with certain configurations, using the tool in a certain
way; and the breakage is nearly silent breakage, just a single warning
line on an already noisy stderr, not explicit error return codes or
status-fd output, while regular output and processing happens on a
different dataset than expected.  These are the hardest kinds of bugs to
deal with in my experience, especially in a tool like GnuPG that is
(correctly!) more often used in scripted or wrapped environments than
executed by the user on the command line.

Anyway, that's the current state of play from my perspective.  I hope
folks who care about GnuPG in debian and are willing to take some risks
will try the packaging in experimental and give feedback.

        --dkg

Attachment: signature.asc
Description: PGP signature

Reply via email to