Thanks for this discussion, all-- On Tue 2025-01-07 15:16:27 +0100, Simon Josefsson wrote: > I believe this would be good, I frequently run into GnuPG bugs in the > 2.2.x branch that was fixed years ago in 2.4
Can you identify some of those bugs? It would be good to be clear about what 2.2 is lacking. For example, if you're talking about [easypg-deadlock], that was a bug introduced on both GnuPG branches at once, and (during GnuPG's stated maintenance window for 2.2) deliberately left unfixed on the 2.2 branch. [easypg-deadlock] https://bugs.debian.org/1071552 a.k.a. https://dev.gnupg.org/T6481 > Andreas, can you give a current status of pending issues for > experimental->unstable upload? Andreas has done great work packaging the 2.4 branch and preparing it for consideration in Debian. As he wrote elsewhere in this thread, 2.4 isn't likely to be supported through the lifetime of trixie either ☹ Aside from GnuPG's ongoing architectural challenges, the thing i personally most want to avoid for Debian would be contributing to the schism where longstanding users of OpenPGP are suddenly migrated to non-OpenPGP artifacts that other OpenPGP implementations can't or won't support. GnuPG seems to be going their own way there, despite documented problems with some of their chosen cryptographic constructs like [v5-v3-signature-aliases] and [encryption-key-separation]. [v5-v3-signature-aliases] https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/130 [encryption-key-separation] https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/101 > It seems there is push from the anti-GnuPG people to promote a fork > called FreePG instead of real GnuPG, will you package that? > > https://gitlab.com/freepg/gnupg All the relevant 2.2 patches in the FreePG repository are already in Debian's unstable branch, and in most cases we have been shipping them for years to address user needs that upstream GnuPG declines to acknowledge or support. I've uploaded 2.2.46 today with our patches renamed to match the names and annotations of this cross-distro effort. I'm gradually trying to push other pieces of our divergence into the FreePG patchset so that other distributions that want to keep shipping GnuPG can arrive at a common and functional baseline. This gives us opportunities to get feedback from other distros as well. In the ideal case, of course, we'd eliminate all our divergence from upstream, but that would depend on upstream being interested in working with the use cases and concerns that our users have. The FreePG project's visibility is also attracting attention from some other downstreams of GnuPG that have distinct fixes that they've been carrying that i hadn't been aware of, and we might end up adopting some of their changes too. If Andreas is interested, i'm happy to do the same alignment with the FreePG patchset on the debian packaging for 2.4 (the debian/experimental branch) too, to gather the same sort of cross-distro consensus. > If so I think there would be value in having the real GnuPG as a > separate Debian package, for those who want to use the real version. Which of the patches in FreePG do you think are harmful for debian users? As someone who has contributed years of labor into making sure GnuPG provides a functional (if not quite as usable or robust as i would like) interface to OpenPGP users on debian and derived distros, our divergence from GnuPG upstream is a carefully curated set that tries to address the most significant problems that upstream has declined to accept. So far, the FreePG patches seem to align pretty closely with that vision (and where they don't align we can either skip them completely, or propose improvements in the FreePG project just as we would with any reasonable upstream). It doesn't seem like normal practice to ask other debian maintainer teams that are carrying patches requested by users but dismissed by upstream to ship "the real version" of the upstream codebase. Is there a reason that GnuPG needs such a process? I welcome review and critique of the packaging for this tricky package, which is pretty deeply embedded in Debian (though getting less so, as apt no longer requires it and we have many other OpenPGP implementations available today). I'd be even more delighted with offers of active co-maintenance beyond the work that Andreas and i have been doing. Regards, --dkg
signature.asc
Description: PGP signature