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
<ludovic.rouss...@free.fr>) protected by SHA-1
Certificate 78A1B4DFE8F9C57E contains a User ID (Ludovic Rousseau
<rouss...@debian.org>) 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
--
Dr. Ludovic Rousseau
