[pkg-gnupg-maint] Bug#852019: Bug#852019: gpgv: unknown type of key resource 'trustedkeys.kbx'

[Daniel Kahn Gillmor]

On Fri 2017-01-20 13:36:57 -0500, Antoine Beaupre wrote:

> For some reason, gpgv fails to verify a file that verifies properly
> with gpg -v:
>
> $ dget https://mentors.debian.net/debian/pool/main/d/dnsdiag/dnsdiag_1.4.0-1.dsc
> dget: retrieving https://mentors.debian.net/debian/pool/main/d/dnsdiag/dnsdiag_1.4.0-1.dsc
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
>                                  Dload  Upload   Total   Spent    Left  Speed
> 100  1489  100  1489    0     0   2534      0 --:--:-- --:--:-- --:--:--  2532
> dget: using existing dnsdiag_1.4.0.orig.tar.gz
> dget: using existing dnsdiag_1.4.0-1.debian.tar.xz
> dnsdiag_1.4.0-1.dsc:
>       Good signature found
>    validating dnsdiag_1.4.0.orig.tar.gz
>    validating dnsdiag_1.4.0-1.debian.tar.xz
> All files validated successfully.
> gpgv: Signature made Sun Jan 15 08:40:29 2017 EST
> gpgv:                using RSA key A3200222CEE5D1A5
> gpgv: Can't check signature: No public key
> dpkg-source: warning: failed to verify signature on ./dnsdiag_1.4.0-1.dsc
> dpkg-source: info: extracting dnsdiag in dnsdiag-1.4.0
> dpkg-source: error: unpack target exists: dnsdiag-1.4.0

This is reasonable.  dget doesn't know about this particular key, so it
can't check the signature.

dget relies on dscverify to verify the file, and dscverify(1) says:

       dscverify  checks that the GPG signatures on the given .changes or .dsc
       files are good signatures made by keys in the current Debian  keyrings,
       found  in  the  debian-keyring and debian-maintainers packages.  (Addi‐
       tional keyrings can be specified using the --keyring option any  number
       of  times.)  It then checks that the other files listed in the .changes
       or .dsc files have the correct sizes and checksums (MD5 plus  SHA1  and
       SHA256  if  the latter are present).  The exit status is 0 if there are
       no problems and non-zero otherwise.

The key in question is not in any of the listed default keyrings, so if
dget verified the .dsc as "ok" it would be a pretty severe bug in dget.

> I can reproduce this with gpgv directly:
>
> $ gpgv dnsdiag_1.4.0-1.dsc       
> gpgv: unknown type of key resource 'trustedkeys.kbx'
> gpgv: keyblock resource '/home/anarcat/.gnupg/trustedkeys.kbx': General error
> gpgv: Signature made Sun Jan 15 08:40:29 2017 EST
> gpgv:                using RSA key A3200222CEE5D1A5
> gpgv: Can't check signature: No public key
>
> It seems there's a problem with some kbx file. Oddly enough, gpg2
> doesn't have that problem:

I suspect that the problem with the listed file is that it doesn't
exist.  i don't have that file either, and i don't plan to -- that file
is treated by gpgv as a curated keyring; if you put something in it,
gpgv will decide that that key can be relied on to make signatures in
general.

gpgv doesn't verify against any old arbitrary stuff in your keyring.
it's designed to be something that can be used correctly and
rigorously -- it needs to know exactly which keys are acceptable for
making a signature, so it needs to be told where those keys are.

AFAICT, the verification process all works fine if i know what i'm
checking against:

    gpg --export 0D35E41F08444E72C1CCC3FF95146A1CBA141817 > mentee.key
    dscverify --no-default-keyring --keyring $(pwd)/mentee.key *.dsc

This also works with "gpgv --keyring $(pwd)/mentee.key *.dsc"

Please note that you have to supply the full path to the keyring because
gpgv assumes that any pathless filename lives in ~/.gnupg/ -- i think
that kind of deviation from convention is bad and unhelpful, but it's
been that way for too long to fix it now.

If anything of the above doesn't work for you, please re-open this bug
report to explain.


> That's bad! It means I need to use the `-u` flag to dget, it breaks
> the trust path to the developr.
>
> I tried verifying the key with the gnupg1 package, which works, but
> that doesn't ship with a gpgv binary anymore, so I can't use that gpgv
> either.

If you want the gpgv1 binary, please install the gpgv1 package :)  It
will have the same behavior

> I wonder if this should be marked as 'grave' because it fails to
> verify valid signatures, but since this is a corner case, I figured i
> would stick with 'important'.

I was considering whether to mark it as "normal" and tag it with
"moreinfo", but i think this report just describes confusion about what
the tools are supposed to do, so i'm going ahead and closing the report
directly.  The tools are all behaving as documented, from what i can
tell.  Please feel free to reopen if i've misunderstood, or if there are
specific changes that you think should be made that don't involve
breaking existing API.

All the best,

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20170123/491159de/attachment.sig>