Hi! On Sun, 2024-12-08 at 21:06:47 +0100, Salvatore Bonaccorso wrote: > Package: devscripts > Version: 2.24.6 > Severity: serious > File: /usr/bin/uscan > X-Debbugs-Cc: debian-ker...@lists.debian.org, car...@debian.org > Control: affects -1 + src:linux
> Note the severity might be overrated, please adjust as needed but I > believe right now it's safer to have it RC until clear on what to do > in other packages. > > While fetching the new upstream version in src:linux the signature > verifification with the new version 2.24.6 fails: > > $ uscan --download-current-version --vcs-export-uncompressed > Newest version of linux on remote site is 6.12.3, specified download version > is 6.12.3 > Cloning into bare repository '../linux-temporary.7164.git'... > remote: Enumerating objects: 91865, done. > remote: Counting objects: 100% (91865/91865), done. > remote: Compressing objects: 100% (89330/89330), done. > remote: Total 91865 (delta 7167), reused 18846 (delta 1562), pack-reused 0 > Receiving objects: 100% (91865/91865), 256.56 MiB | 7.13 MiB/s, done. > Resolving deltas: 100% (7167/7167), done. > gpgv: Signature made vr 06 dec 2024 07:20:53 CET > gpgv: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E > gpgv: Can't check signature: No public key > uscan die: OpenPGP signature did not verify. at > /usr/share/perl5/Devscripts/Uscan/Output.pm line 77. > > This works with the 2.24.5 version. This is a consequence of the switch from gpg to gpgv, which has now surfaced issues in how the certificates are stored in the Linux packaging (and while checking this also in the certificates themselves). The first issue is that the debian/upstream/signing-key.asc uses concatenated ASCII Armored certificate blocks, which is not a well defined construct, see: <https://bugs.debian.org/969588> <https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/28> <https://bugs.debian.org/969590> This should also affect the verification from dpkg-source. You can fix this by running something like: $ sq keyring merge debian/upstream/signing-key.asc | sponge debian/upstream/signing-key.asc The other is that many certificates listed there should not be considered valid anyway as they use weak constructs (gpgv from GnuPG currently considers them fine but gpg-from-sq for example will not, and neither any of the other SOP implementations), and that also reminds me that we should be passing to gpg/gpgv in uscan and any other devscripts invocation «--weak-digest SHA1 --weak-digest RIPEMD160» (I'll queue a patch in my upcoming GnuPG cleanup branch). Running either «sq inspect debian/upstream/signing-key.asc» or «sq cert lint --cert-file=debian/upstream/signing-key.asc» (from sid) will show issues such as: ,--- Certificate 38DBBDC86092693E is not valid under the standard policy: No binding signature at time 2024-12-09T02:08:50Z Certificate 38DBBDC86092693E contains a User ID ("Greg Kroah-Hartman (Linux kernel stable release signing key) <g...@kroah.com>") protected by SHA-1 Certificate 38DBBDC86092693E, key F38153E276D54749 uses a SHA-1-protected binding signature. Certificate 79BE3E4300411886 is not valid under the standard policy: No binding signature at time 2024-12-09T02:08:50Z Certificate 79BE3E4300411886 contains a User ID ("Linus Torvalds <torva...@linux-foundation.org>") protected by SHA-1 Certificate 79BE3E4300411886, key 88BCE80F012F54CA uses a SHA-1-protected binding signature. Certificate DEA66FF797772CDC contains a User ID ("Sasha Levin <alexander.le...@verizon.com>") protected by SHA-1 Certificate DEA66FF797772CDC contains a User ID ("Sasha Levin <sasha.le...@oracle.com>") protected by SHA-1 Certificate DEA66FF797772CDC, key D0065D755EB09DBB uses a SHA-1-protected binding signature. Examined 4 certificates. 0 certificates are invalid and were not linted. (GOOD) 4 certificates were linted. 3 of the 4 certificates (75%) have 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. 4 of the non-revoked linted certificates have at least one non-revoked User ID: 3 have at least one User ID protected by SHA-1. (BAD) 2 have all User IDs protected by SHA-1. (BAD) 4 of the non-revoked linted certificates have at least one non-revoked, live subkey: 3 have 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: 3 certificates have at least one issue `--- So you might also want to contact upstream developers to sort out their certificates. Thanks, Guillem
