XPost: linux.debian.maint.dpkg
Hi!
On Tue, 2025-05-20 at 15:36:40 +0300, Martin-Éric Racine wrote:
ti 20.5.2025 klo 15.07 Guillem Jover (guillem@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).
Given GnuPG's move to its own non-standard format for its trustedkeys
keyring (the keybox format), reusing that for other implementations is
no longer an option, and was kept as a GnuPG specific behavior, but
this is becoming an annoying divergence.
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.
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.
Hope that clarifies.
I've also updated the current pre-approval/unblock report against the
release team for a proposed new upload fixing this confusing error
handling.
Thanks,
Guillem
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)