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

Tue Jan 24 20:13:29 UTC 2017

On 2017-01-23 21:34:37, Daniel Kahn Gillmor wrote:
> 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 see.

>> 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.

If no one ise going to use that file on a regular basis - maybe its
absence shouldn't generate a worrisome "General error"...

> 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"

I confirm this works for me.

Unfortunately, there's no --keyring argument to dget, so there's no way
to check the signatures before fiels are extracted...

> 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.

Understood, that's not too much of a problem.

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

I understand the logic better now.

In my opinion, it is problematic that gpgv doesn't check the file
integrity when the key is not present. Or, more precisely, it seems that
the signatures *are* checked, but there are conflicting messages
here. On the one hand, dget tells me:

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.

and on the other hand, gpgv tells me:

gpgv: Signature made dim 15 jan 2017 08:40:29 EST
gpgv:                using RSA key A3200222CEE5D1A5
gpgv: Can't check signature: Pas de clef publique

so which one is it? did the checksums verify or not? and note that there
are two layers of checksums here - the sha256sums in the .dsc file, and
the OpenPGP checksum of the .dsc file itself.

It is completely unclear what is going on here. I don't know if:

 1. the checksums match the files (ie. all sha256sums match the files)

 2. the checksums match the OpenPGP signature (ie. the OpenPGP signature
    on the .dsc file is correct)

 3. the OpenPGP signature matches the key I have in my keyring

You basically answered question #3 here: it doesn't check against my
keyring by design. I would question that decision, because I'd rather
check against a key I trust on first use than not check at all. In fact,
why doesn't this leverage my trust database I am carefully curating
every once in a while?

I understand that for AptSecure, there's a dedicated keyring and
everything. That makes perfect sense to me. But this is me, as a
developper, downloading a package from a mentoree. The trust path to
that person is tenuous even in the best scenario - why put more hurdles
in the way to check that signature?

But okay, let's say gpgv can only check against a curated keyring. We
still have the huge usability issue that we don't actually know which
checksums match and how. Even if I don't have a key, I should be able to
verify the OpenPGP signature on it, no?

Maybe this is simply a usability bug in devscripts/dget/dscverify.

>> 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

Right, I see.

>> 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.

Well, I don't want to get into a reopening argument. If this is just me,
we can move on.

But it seems that one of the key issues in crypto is usability, and the
messages here are mixed, at best, and utterly confusing for me, in this
use case.

I often try to sponsor packages for new people, and this confuses the
hell out of me every time. ;)

A.

-- 
Tu connaîtras la vérité de ton chemin à ce qui te rend heureux.
                        - Aristote