Bug#1100867: gpgv: Can't check signature: No public key

Le 20/03/2025 à 00:51, Guillem Jover a écrit :
> The problem is that the old openpgp-check hook implementation was
> ignoring some verification failures, and silencing stdout/stderr from
> the OpenPGP command being used. I assume that with an older dupload you
> should have seen the following message instead:
> 
>    "  OpenPGP signature in $FILE cannot be checked, maybe due to missing keys"
> 
> (or something similar).

No. No warning at all.

With dupload 2.9.12 I have:
$ dupload ccid_1.6.2-1_source.changes --no
dupload note: no announcement will be sent.
Checking OpenPGP signatures before upload......signatures are ok
Uploading (scpb) to ssh.upload.debian.org:/srv/upload.debian.org/UploadQueue/
[ Preparing job ccid_1.6.2-1_source from ccid_1.6.2-1_source.changes
  ccid_1.6.2-1.debian.tar.xz, size ok, md5sum ok, sha1sum ok, sha256sum ok
  ccid_1.6.2-1.dsc, size ok, md5sum ok, sha1sum ok, sha256sum ok
  ccid_1.6.2-1_amd64.buildinfo, size ok, md5sum ok, sha1sum ok, sha256sum ok
  ccid_1.6.2.orig.tar.xz, size ok, md5sum ok, sha1sum ok, sha256sum ok
  ccid_1.6.2.orig.tar.xz.asc, size ok, md5sum ok, sha1sum ok, sha256sum ok
  ccid_1.6.2-1_source.changes ok ]
Uploading (scpb) to debian-ssh (ssh.upload.debian.org)
[ Uploading job ccid_1.6.2-1_source
  ccid_1.6.2-1.debian.tar.xz 10.8 kB, ok
  ccid_1.6.2-1.dsc 2.1 kB, ok
  ccid_1.6.2-1_amd64.buildinfo 7.0 kB, ok
  ccid_1.6.2.orig.tar.xz 192.5 kB, ok
  ccid_1.6.2.orig.tar.xz.asc 0.8 kB, ok
  ccid_1.6.2-1_source.changes 2.4 kB, ok
+ scp   ccid_1.6.2-1.debian.tar.xz ccid_1.6.2-1.dsc ccid_1.6.2-1_amd64.buildinfo ccid_1.6.2.orig.tar.xz ccid_1.6.2.orig.tar.xz.asc ccid_1.6.2-1_source.changes  ssh.upload.debian.org:/srv/upload.debian.org/UploadQueue/
+ log to ccid_1.6.2-1_source.upload

+ log successful upload
  ]

I was able to upload using this version of dupload and the package is now in unstable.
https://packages.debian.org/search?keywords=libccid

So my GnuPG key is still recognised as valid by the Debian server(s).

> The problem is that your key does not appear valid to GnuPG or other
> OpenPGP implementations. Running the Sequoia certificate linter (from
> the «sq» package) gives this:
> 
>    ,---
>    $ sq cert lint --cert F5E11B9FFE911146F41D953D78A1B4DFE8F9C57E
>    Certificate 78A1B4DFE8F9C57E is not valid under the standard policy: No binding signature at time 2025-03-19T23:36:51Z
>    Certificate 78A1B4DFE8F9C57E contains a User ID (Ludovic Rousseau <[email protected]>) protected by SHA-1
>    Certificate 78A1B4DFE8F9C57E contains a User ID (Ludovic Rousseau <[email protected]>) protected by SHA-1
>    Certificate 78A1B4DFE8F9C57E, key 36A241532F1BEFF0 uses a SHA-1-protected binding signature.
>    Examined 1 certificate.
>      0 certificates are invalid and were not linted. (GOOD)
>      1 certificate was linted.
>      1 of the 1 certificates (100%) has at least one issue. (BAD)
>    0 of the linted certificates were revoked.
>      0 of the 0 certificates has revocation certificates that are weaker than the certificate and should be recreated. (GOOD)
>    0 of the linted certificates were expired.
>    1 of the non-revoked linted certificate has at least one non-revoked User ID:
>      1 has at least one User ID protected by SHA-1. (BAD)
>      1 has all User IDs protected by SHA-1. (BAD)
>    1 of the non-revoked linted certificates has at least one non-revoked, live subkey:
>      1 has at least one non-revoked, live subkey with a binding signature that uses SHA-1. (BAD)
>    0 of the non-revoked linted certificates have at least one non-revoked, live, signing-capable subkey:
>      0 certificates have at least one non-revoked, live, signing-capable subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD)
> 
>      Error: 1 certificate have at least one issue
>    `---
> 
> You should be able to fix your key by following the instructions in
> <https://book.sequoia-pgp.org/lint.html>. The same could be done with
> GnuPG, but it's way way more tedious (see
> <https://lore.kernel.org/keys/fxotnlhsyl2frp54xtguy7ryrucuwselanazixeax3motyyoo3@7vf7ip6gxyvx/T/#u>
> in case you prefer that).

I used:
$ sq cert lint --fix --output - --cert F5E11B9FFE911146F41D953D78A1B4DFE8F9C57E | gpg --import

and now the key is OK for Sequoia:
$ sq cert lint --cert F5E11B9FFE911146F41D953D78A1B4DFE8F9C57E
Examined 1 certificate.
   0 certificates are invalid and were not linted. (GOOD)
   1 certificate was linted.
   0 of the 1 certificates (0%) have at least one issue. (GOOD)
0 of the linted certificates were revoked.
   0 of the 0 certificates has revocation certificates that are weaker than the certificate and should be recreated. (GOOD)
0 of the linted certificates were expired.
1 of the non-revoked linted certificate has at least one non-revoked User ID:
   0 have at least one User ID protected by SHA-1. (GOOD)
   0 have all User IDs protected by SHA-1. (GOOD)
1 of the non-revoked linted certificates has at least one non-revoked, live
subkey:
   0 have at least one non-revoked, live subkey with a binding signature that uses SHA-1. (GOOD)
0 of the non-revoked linted certificates have at least one non-revoked, live,
signing-capable subkey:
   0 certificates have at least one non-revoked, live, signing-capable subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD)

I will upload it to update the keyring.

> Although this looks like a problem with the key and not with dupload,
> I'll leave this open, and then add a hint to its output to try to help
> others in a similar situation as yours.

Good idea.
I guess the problem is the use of SHA-1.

I think other DD with have the same problem.
Maybe you could check all the keys present in the keyrings.

Thanks