Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x
Hello, NIIBE Yutaka wrote: > I backported and pushed my changes to tmp-gniibe-v2.4. > > https://salsa.debian.org/gniibe/gnupg2 > > This is Debian compatible version of GnuPG 2.4.1. Today, I merged 2.4.3 from Andreas Metzler's tmp-ametzler-v2.4 branch. This is Debian compatible version of GnuPG 2.4.3. I just started to use this GnuPG on my system. --
Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x
NIIBE Yutaka wrote: > I'm going to backport the improvement to my branch of tmp-gniibe-v2.4 > for Debian. I backported and pushed my changes to tmp-gniibe-v2.4. https://salsa.debian.org/gniibe/gnupg2 This is Debian compatible version of GnuPG 2.4.1. --
Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x
NIIBE Yutaka wrote: > I was wrong. The ticket for agent_cache_housekeeping is: > > https://dev.gnupg.org/T3829 > > It was introduced because of some risk keeping passphrase. > > I'd like to consider to improve the implementation of cache and > expiration, not using handle_tick. In the upstream, I created a ticket for this task. https://dev.gnupg.org/T6681 Then, I did some work. I believe that I somehow sorted out and deal with problems for T3829 and gpg-agent-idling. I'm going to backport the improvement to my branch of tmp-gniibe-v2.4 for Debian. * * * During my implementing the code for T6681, I realized that the possible reason why Christoph disabled use of debian/patches/gpg-agent-idling when he packaged 2.3.1-1; The patches were written in Oct/Nov of 2016. In 2018, to solve an issue of T3829, cache expiration code was added at the handle_tick function. --
Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x
NIIBE Yutaka wrote: > Besides, in my opinion, the agent_cache_housekeeping function makes less > sense (it's totally OK to only check the expiration on its use). Having > expired entries on memory is no problem at all, than running gpg-agent > process periodically; memory is cheap but buttery power is not (for my > use case). I was wrong. The ticket for agent_cache_housekeeping is: https://dev.gnupg.org/T3829 It was introduced because of some risk keeping passphrase. I'd like to consider to improve the implementation of cache and expiration, not using handle_tick. --
Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x
NIIBE Yutaka wrote: > Based on your work of tmp-ametzler-v2.4 branch, I created my own fork. > > My hope is that the migration from 2.4 won't introduce (much) surprise > to Debian users. > >https://salsa.debian.org/gniibe/gnupg2/-/tree/tmp-gniibe-v2.4 > > This work of mine is: > > - Keep systemd support (despite its deprecation in upstream) > - Introduce keyboxd package (with systemd support, for integrity) > - Put backport of BEGIN_ENCRYPTION status output (from master of upstream) Further, I recover the patches/gpg-agent-idling series. - Enable patches/gpg-agent-idling In the upstream, scd monitoring has improved by introducing a watching thread. I updated the patches to address this change of scd monitoring. Actually, we can improve the code more. On Windows, since parent_pid is always -1 (running command by gpg-agent is not supported), the need_tick function should return 0. And the return value of the need_tick function is determined at initialization, we can clean up the code. Besides, in my opinion, the agent_cache_housekeeping function makes less sense (it's totally OK to only check the expiration on its use). Having expired entries on memory is no problem at all, than running gpg-agent process periodically; memory is cheap but buttery power is not (for my use case). --
Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x
Hello, Andreas Metzler wrote: > On 2023-04-30 Andreas Metzler wrote: > [...] >> However I have updated the GIT branches to 2.4.1 today. > > Now at 2.4.3. Based on your work of tmp-ametzler-v2.4 branch, I created my own fork. My hope is that the migration from 2.4 won't introduce (much) surprise to Debian users. https://salsa.debian.org/gniibe/gnupg2/-/tree/tmp-gniibe-v2.4 This work of mine is: - Keep systemd support (despite its deprecation in upstream) - Introduce keyboxd package (with systemd support, for integrity) - Put backport of BEGIN_ENCRYPTION status output (from master of upstream) It doesn't (yet) have TPM support and update to 2.4.3. I don't insist that it's a solution. I am in seek of a point of possible agreement/compromise for Debian users. The current choice would be rather arbitrary (it's based on my use case on Debian), but I believe that the packages will provide less surprise. --
Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x
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
Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x
Christian Kastner writes: > Hi Daniel, > > On 2023-06-12 17:01, Sune Stolborg Vuorela wrote: >> Any chance you can give Andreas a go ahead to push a newer Gnupg2 to at >> least >> experimental, or preferably unstable ? > > I, too, would appreciate a newer version. It turns out that in versions > prior to 2.3, the 'kdf-setup' option with cards does not work [1]. At > least, that was the case with both Yubikeys and Nitrokeys here on my end. How about uploading ametzler's branch to experimental, as a start? It is good time after the bookworm release. I offer to help maintain GnuPG in Debian. Perhaps uploading it to mentors would be a first step, any objections? There are some new features in GnuPG 2.4.x that I rely on, having to build it locally is a pain. /Simon signature.asc Description: PGP signature
Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x
Hi Daniel, On 2023-06-12 17:01, Sune Stolborg Vuorela wrote: > Any chance you can give Andreas a go ahead to push a newer Gnupg2 to at least > experimental, or preferably unstable ? I, too, would appreciate a newer version. It turns out that in versions prior to 2.3, the 'kdf-setup' option with cards does not work [1]. At least, that was the case with both Yubikeys and Nitrokeys here on my end. Best, Christian [1] https://dev.gnupg.org/T3891#142195
Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x
On Sunday, April 30, 2023 1:27:14 PM CEST Andreas Metzler wrote: > I do not indend to hijack/adopt gnupg2, so I am very reluctant to upload > without some kind of go from Daniel or Eric. (Even to experimental.) Hi Daniel Any chance you can give Andreas a go ahead to push a newer Gnupg2 to at least experimental, or preferably unstable ? Kind regards, /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank
