Control: clone 1095451 -1 Control: retitle -1 With use-keyboxd, gpg ignores all --keyring arguments Control: reopen -1 Control: found -1 2.4.7-4 Control: forwarded -1 https://dev.gnupg.org/T7265
On Sat 2025-02-08 07:35:41 +0100, Andreas Metzler wrote: > Andreas Klode gave us a heads-up about this in > https://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/2024-March/009235.html > | after a report of gnupg 2.4 breaking some tooling in Ubuntu[1], we > | analysed it and found out that if `use-keyboxd` is set, gpg just > | silently ignores any keyring arguments, as it only takes public > | keys stored in keyboxd. > | > | On new installs, aka. if ~/.gnupg does not exist, gnupg automatically > | enables keyboxd by writing `use-keyboxd` to common.conf. > | > | I just patched Ubuntu's GnuPG to not do that, I think this may be > | the right call for Debian as well. > https://git.launchpad.net/ubuntu/+source/gnupg2/tree/debian/patches/no-keyboxd.patch?h=ubuntu/plucky-devel > > This was/is for 2.4.4, 2.4.7 does not ignore keyring arguments > *silently*: > (sid)ametzler@argenau:/tmp/GNUPG2$ gpg --keyring /tmp/GNUPG2/blah.gpg --verify > gnupg2_2.4.7.orig.tar.bz2.asc > gpg: Note: Specified keyrings are ignored due to option "use-keyboxd" > [...] > > How important/important is the usecase of --keyring without --homedir > and without a custom gpg configuration in ~/.gnupg? > >> I'm not sure what the right solution is here; perhaps the simplest thing >> would be to just ship the keyboxd binary (and socket activation, etc) >> directly in the gpg package, and have that package Provides: keyboxd. > > If there is no strong reason to divert from upstream keyboxd preference > we shoud follow it. And if we do your proposal sounds good. Thanks for pointing to this previous discussion, Andreas. I don't think the underlying issue here is whether the user gets opted into keyboxd by default or not -- though that certainly aggravates the situation, and maybe we should adopt JAK's suggestion as a mitigation. It looks to me like the underlying issue is that gpg 2.4.x will behave differently for those who use keyboxd than for those who don't, regardless of who has opted in. So, for example, a tool that uses --keyring=XXX will behave one way for a user with use-keyboxd set, and another way entirely (albeit with one extra line of warning on stderr for 2.4.7+) for a user without use-keyboxd set. I've reopened the upstream ticket and i'm pointing to it here, because this seems like a situation that will give rise to very obscure bugs. Perhaps we need to offer a patch to GnuPG that: - warns about the use of --keyring everywhere, and - fails hard (including messages to the status-fd) if --keyring is used in conjunction with keyboxd What do you think? --dkg PS in any case, i think rolling keyboxd into the gpg package (as i've done with 2.4.7-4) is probably a reasonable thing to do anyway. As gpg becomes less central to the Debian ecosystem, i have less of a problem if gpg itself is a bigger package. and if gpg can't actually do *anything* without keyboxd for an installation with use-keyboxd set, i'm not sure what we gain from having it split out.
signature.asc
Description: PGP signature
