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
signature.asc
Description: PGP signature