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