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

Attachment: signature.asc
Description: PGP signature

Reply via email to