Hi Simon-- It's pretty clear from the discussion on debian-devel that we disagree on the merits of injecting non-consensus LibrePGP artifacts into the existing OpenPGP ecosystem, so i'm not going to discuss that directly in this ticket.
I also don't think having three different versions of GnuPG in debian is a great idea, but obviously i am not going to block you from doing this if you really want to take this approach. I think it's bad enough that we continue to ship a gpg1 package, which, despite upstream claims of ongoing "classic" support, is really not fit for purpose with modern cryptography in 2025. Users who run /usr/bin/gpg24 will need to think about how it interacts with the ~/.gnupg/ that is likely also in use by /usr/bin/gpg. Depending on the variations between the versions, and given GnuPG's historically unclear boundaries on the expectations of interactions with the "homedir", that could be an interesting outcome. On Tue 2025-01-14 18:03:14 +0100, Simon Josefsson wrote: > The intent with this package is to provide a LibrePGP-compliant variant > of GnuPG in Debian. > > Packaging is based on the 'gnupg2' source package from experimental, and > will be maintained here: > > https://salsa.debian.org/debian/gnupg-24/ > > The idea is to minimize the existing packaging into the most minimal set > of binary packages required to support a more upstream-like GnuPG 2.4.x > experience in Debian. Have you reviewed the current patchset in debian/patches, and the additional files in debian/? One of the major divergences from upstream in debian is our ongoing support of the multi-daemon session integration with systemd, which is explicitly deprecated and disapproved by upstream. (it seems clear to me that today, systemd is the dominant session manager for Debian GNU/Linux systems; if folks want to argue about whether that is true, it should probably be done somewhere other than this ticket). As far as i understand, GnuPG 2.4 provides 4 long-running daemons: - keyboxd - gpg-agent - dirmngr - scdaemon Sensible integration with systemd means reducing startup time for gpg processes and provides reasonable automated daemon termination policy (e.g. daemon termination at logout). Nonetheless, GnuPG upstream rejects > Hopefully only two new binary packages called 'gpg24' and 'gpgv24' will > be needed. > > I am hoping that most of the auxilliary packages like scdaemon does not > need to be provided by this source package, but can be shared with the > GnuPG/FreePG variant already packaged in Debian in the 'gnupg2' source > package. If you want to avoid systemd socket activation for the long-running daemons, you'll probably need to modify those packages as well. If you're shipping those daemons separately, please also consider other changes that we've made to accomodate use cases that upstream doesn't care about, like battery drain from the long-running daemons, blocking trivial memory dumps of gpg-agent, acknowledging cryptographically valid OpenPGP certificate revocation information even in absence of a user ID, etc. Regards, --dkg
signature.asc
Description: PGP signature
