Daniel Kahn Gillmor <d...@debian.org> writes: > 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
I don't think that is a neutral way of expressing the situation. The situation seems to be that there are two set of implementations that have chosen to not interoperate with the other set. Where to cast the blame depends on which perspective you take. Reversely, the first implementations to support a superset of approaches is likely to be seen as a constructive force in this mess. >> 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? Let's reverse it: Which of the patches in FreePG do you think are useful for Debian users? Who is behind FreePG? The group is created by pseduonyms with no earlier contributions: https://gitlab.com/groups/freepg/-/group_members Do we want to trust the GnuPG author on what GnuPG should be? Or do we want to trust 'Hooty McOwlface' with no earlier publicly recorded community contributions? > 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. I've offered help, but my impression has been that it not giving up on the schism thing has been more important than getting Debian to ship upstream code to users and let people decide what they want to use. Sometimes it is better to let other make decisions rather than to make decisions for others. /Simon
signature.asc
Description: PGP signature
