ke 21.5.2025 klo 12.03 Guillem Jover (guil...@debian.org) kirjoitti:
> On Tue, 2025-05-20 at 15:36:40 +0300, Martin-Éric Racine wrote:
> > ti 20.5.2025 klo 15.07 Guillem Jover (guil...@debian.org) kirjoitti:
> > > On Tue, 2025-05-20 at 14:52:59 +0300, Martin-Éric Racine wrote:
> > > > As far as I can tell, the key issue is that gpgv knows about the
> > > > user's personal keyring (which, in my case, has the key of many DD/DM,
> > > > as a result of previous key signing parties) as well as system
> > > > keyrings, while sqv seemingly doesn't.
> > >
> > > Sorry that I was not more clear. When verifying signatures using any of
> > > the GnuPG implementation commands (gpg or gpgv), we never use the user
> > > home directory (and neither its pubring.{pgp,kbx} keyrings), the only
> > > thing from the GnuPG home directory we try to use is the
> > > ~/.gnupg/trustedkeys.{gpg,kbx} keyring if present, but those do not get
> > > automatically populated by gpg (AFAIR). So I'm assuming you might
> > > have added your own certificate there (and perhaps a select few?), and
> > > if so that would mean you would not be able to verify other source
> > > packages that are signed by other people.
> >
> > I never said that they get automatically populated. I said that if the
> > key used to sign the package is present in ~/.gnupg/*, gpgv apparently
> > knows how to use it, while sqv seemingly doesn't.
>
> > FWIW, I purposely don't install debian-keyring, because the unpacked
> > file is huge, and gpgv knows how to source the key from ~/.gnupg/* as
> > needed.
>
> I was trying to clarify what seemed like an apparent misconception,
> while trying to infer from missing context. But I think I failed. :)
> Let me try again, just in case (even possibly if you know some or most
> of it :).
>
> By default gpg(1) uses its home directory to reach for certificates and
> keys under ~/.gnupg/pubring.{kbx,gpg} and ~/.gnupg/private-keys-v1.d/*
> respectively (but never ~/.gnupg/trustedkeys.{kbx,gpg}). By default
> gpgv(1) uses only any keyring specified by any explicit --keyring
> argument, and only if no such argument has been specified it will try
> to use ~/.gnupg/trustedkeys.{kbx,gpg} if it exists.
>
> The GnuPG support in dpkg (AFAIR), has never used (or at least for a
> very long time) the GnuPG home directory for signature verification, it
> has always created a temporary home directory to avoid it implicitly
> reading any of the GnuPG keyrings. As an exception though, that dpkg
> support has always passed explicitly the trustedkeys keyring (if
> present) to the list of keyrings to either gpg or gpgv (which diverges
> from both default tools behavior).I'm pretty sure that it did given how, until now, it succesfully verified signatures despite debian-keyring not being installed. If debian-keyring isn't installed, those signatures had to be found somewhere, right? > I hear what you say about the Debian keyring being too big, and the > desire for the usage of a curated user keyring, so for 1.23.x I'll be > adding generic support to be able to specify an OpenPGP formatted > keyring for such cases to all OpenPGP implementation, and then > deprecate the GnuPG specific trustedkeys keyring support. Thanks! > Also a note that after apt switched from gpgv to sqv, and before dpkg > grew support for sqv, on minimal installations (with no gpgv or any > other supported OpenPGP implementation present), dpkg-source would not > verify signatures at all (it does not even print a warning if there is > no OpenPGP tool available for it to use). I've got some patches and > some thoughts to make this all more explicit for 1.23.x though. That could work, although it would stop verifying signatures by default, which is what we've had until now. I'm not sure that discontinuing that default is a good idea. Martin-Éric
