On 2025-02-08 Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: > 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. [...] > > This was/is for 2.4.4, 2.4.7 does not ignore keyring arguments > > *silently*: [...] > > 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. Hello Daniel, I would rather not change a default without a stronger rationale. > 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? That makes perfectly good sense. How about waiting a week or so for feedback on this on the upstream report? cu Andreas
