Hi all-- Many apologies for the delayed response on this thread, and my recent delays on GnuPG in debian generally. My time has been lacking here, and my relationship with GnuPG upsteam is sadly strained, though i wish it were not.
I really appreciate the work that other folks have put in here to think through next steps, and i don't want to stand in anyone's way. I've always tried to do my work on GnuPG in debian within a team context, and with my strong belief in LowNMU as well, i'm not interested in being a blocker. I have some concerns about the suitability of newer versions of GnuPG for decent system integration on current GNU/Linux systems, and for OpenPGP ecosystem interoperability, which have led me to shy away from deliberately packaging the 2.4.x series directly for Debian; i don't know how to resolve those concerns. But that doesn't mean that other people who are eager to tackle these problems shouldn't work on it. And, to the extent that i have time to offer review, i'd be happy to weigh in. But i don't want anyone with the capability and interest to do this work to be waiting on me. The libgpg-error packaging Andreas as produced for experimental looks to me like it should probably be uploaded to unstable directly, as that's useful work regardless of what version of GnuPG is in the archive. Thank you, Andreas! Thank you also to gniibe for his work toward improving smartcard accessibility! How we move ahead with newer versions of the gnupg2 and gpgme1.0 source packages might be a bit trickier, but i trust the good people on this thread to think through those concerns. Below, i describe some of my concerns around the 2.4.x series that have kept me from figuring out how to do useful work here, but none of them should be taken as blocking objections. They're just background for folks who are considering this packaging work. Some of these concerns resonate for me even with the 2.2.x series as well, but i think they're heightened in the 2.4.x series. It's also possible that i'm wrong about any of these details, and i welcome any corrections. - GnuPG's use of long-running daemons has a complicated history. I generally like the idea of long-running services that can share load between and isolate risk across multiple running processes. But the reality of the integration is that it just hasn't practically worked well for this project. Upstream's standard approach for launching necessary daemons is associated with a history of race conditions (https://bugs.debian.org/868550), unnecessary delays (https://dev.gnupg.org/T3490), excess power consumption (https://dev.gnupg.org/T1805), configuration/state confusion (https://dev.gnupg.org/T4513) and failure to shutdown/cleanup correctly at logout (https://dev.gnupg.org/T2858). Some of these problems were mitigated on debian (at least for the standard GnuPG homedir) by the use of systemd user services with socket activation, much of which was adopted upstream. Debian has also for years carried additional patches that i tried to forward into upstream to improve some of the problems above (e.g. https://lists.gnupg.org/pipermail/gnupg-devel/2016-November/032011.html) but they haven't landed and they are increasingly difficult to maintain. In the 2.2 series, GnuPG relied on long-running daemons for secret key access (gpg-agent), smartcard access (scdaemon), and network access (dirmngr). In the 2.4 series, GnuPG uses all of the above and additionally depends on a long-running daemon for public key access (keyboxd). Furthermore, in the 2.4 series, i understand that the systemd integration has been removed, which means that many of the potential problems with upstream's approach for daemon-handling are likely to recur. I hope a responsible packager for debian will think about how to address these system integration issues, even if they are not personally affected by them (e.g. if you run GnuPG as a single user, never doing parallel invocations of GnuPG, on a desktop computer with a stable network connection and no worries about power consumption, and you hardly ever log out of the system). If we want this tooling to work for normal users who might vary from any of the above conditions, then we need some more plausible, usable answers than "just remember to run 'gpgconf --killall $DAEMON_NAME' when you log out/change networks/switch to battery power/etc". Werner mentioned some of these concerns on this thread already, and objected to service management on the grounds that it should work the same way on all platforms. But that's not how i imagine system integration to work. On systems that manage services in a specific way, quality system integration should make each project-specific service work the way the system generally works. This is surely a burden of cross-platform maintenance, but it comes with the territory. - GnuPG's 2.4.x series encourages the use of a variant of the OpenPGP wire format that was developed without reaching consensus of the broader OpenPGP community. There are a handful of specific technical problems with these formats (e.g. GnuPG's proposed "version 5 signatures" can be aliased into v3 signatures over a subtly different bytestream, https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/130, and its form of encrypted data risks having session key reuse across different algorithms https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/101), but more generally the past failure to reach consensus among the half-dozen OpenPGP projects that were participating in the revision process that petered out on GnuPG's implementation suggests a potential ecosystem fragmentation. As a co-chair of the OpenPGP working group at the IETF, i have to own that failure to reach consensus at least as much as anyone else. But in the last year, the same WG has reached a rough consensus reached that resolves these issues, and it's not clear that GnuPG will implement it (though i certainly hope the project will). I believe all the building blocks are in place within GnuPG 2.4 and gcrypt to implement the newer wire formats (SEIPDv2 and v6 keys+sigs), so GnuPG could advance the state of the field as it has in the past. However, if GnuPG upstream declines to do that implementation, and as v6 keys+sigs and SEIPDv2 messages become more widely available, any debian maintainer of GnuPG will face pressures from users to either patch GnuPG to handle the new formats or to push those changes upstream. I wish i was confident enough in my relationship with the GnuPG project to be able to shepherd those changes upstream *and* in Debian, but my failure to get even relatively simple changes upstreamed that reduce, say, daemon power consumption doesn't suggest that i'm well equipped to do that. When it comes to protocol wire format issues, i haven't even been able to convince GnuPG upstream for years to accept commonplace sensible indicators of revocation (e.g. pubkey packet + revocation packet) as witnessed by debian/patches/import-merge-without-userid/*.patch and, e.g. https://dev.gnupg.org/T4393 . Werner also mentioned this upthread and i respectfully disagree with him here. This is not about choice of keyserver network (though it does touch on that), but about users being able to identify revoked keys when presented with cryptographically compelling evidence of revocation. In summary, I don't know how to convince upstream that these wireformat issues warrant adoption by GnuPG, and i don't know how to resolve the inevitable tensions we'll face within Debian as user demand for these features increases. At any rate, i welcome other maintainers to work on the project of keeping GnuPG well-integrated with debian, and to the extent that i have time/capacity to help (and particularly where i won't cause additional hindrance) i would be happy to pitch in. GnuPG is an important piece of our free software infrastructure, and it needs the attention folks here seem poised to give it. I hope i can be helpful going forward, and i do not at all resent any attempts to address these larger issues. All the best, --dkg
signature.asc
Description: PGP signature