[Pkg-rust-maintainers] Bug#1118154: sqopv does not seem to support some signing keys
Guillem Jover
guillem at debian.org
Thu Oct 16 22:56:59 BST 2025
Hi!
On Wed, 2025-10-15 at 16:09:51 +0200, Ben Hutchings wrote:
> Package: sqopv
> Version: 0.37.2-2
> Severity: important
> With sqopv installed, uscan fails to verify some signed Git tags for
> which the signature is accepted by gpgv and rsopv.
>
> For example, using the attached files:
>
> $ gpg --dearmor < keyring.asc > keyring.pgp
> $ gpgv --keyring ./keyring.pgp signature plaintext
> gpgv: Signature made Fri 08 Aug 2025 14:09:09 CEST
> gpgv: using RSA key 4CDE8575E547BF835FE15807A31B6BD72486CFD6
> gpgv: Good signature from "Josh Boyer <jwboyer at fedoraproject.org>"
> gpgv: aka "Josh Boyer <jboyer at redhat.com>"
> gpgv: aka "Josh Boyer <jwboyer at gmail.com>"
> gpgv: aka "Josh Boyer <jwboyer at redhat.com>"
> $ rsopv verify signature keyring.asc < plaintext
> 2025-08-08T12:09:09Z 4cde8575e547bf835fe15807a31b6bd72486cfd6 4cde8575e547bf835fe15807a31b6bd72486cfd6 mode:binary {"signers":["keyring.asc"]}
> $ sqopv verify signature keyring.asc < plaintext
> No acceptable signatures found
The attached certificate has SHA-1 issues:
,---
$ sq cert lint <keyring.asc
Certificate A31B6BD72486CFD6 is not valid under the standard policy: No binding signature at time 2025-10-16T21:45:01Z
Certificate A31B6BD72486CFD6 contains a User ID (Josh Boyer <jboyer at redhat.com>) protected by SHA-1
Certificate A31B6BD72486CFD6 contains a User ID (Josh Boyer <jwboyer at fedoraproject.org>) protected by SHA-1
Certificate A31B6BD72486CFD6 contains a User ID (Josh Boyer <jwboyer at gmail.com>) protected by SHA-1
Certificate A31B6BD72486CFD6 contains a User ID (Josh Boyer <jwboyer at redhat.com>) protected by SHA-1
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)
0 of the non-revoked linted certificates have 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)
Error: 1 certificate have at least one issue
`---
Doing a «sq network search 4CDE8575E547BF835FE15807A31B6BD72486CFD6»
and then «sq cert lint --cert 4CDE8575E547BF835FE15807A31B6BD72486CFD6»
gives a bit better results though.
«sq inspect keyring.asc» gives similar reasons.
On Wed, 2025-10-15 at 16:55:46 +0200, Ben Hutchings wrote:
> To support the bug title, I did a comparison of the different OpenPGP
> implementations for all the upstream signed tags for src:linux.
>
> Git normally wants to run gpg and expects any alternative to implement
> the same options and output format, so I implemented wrapper scripts to
> make it work with the different verifier commands all using
> debian/upstream/signing-key.asc as the keyring.
>
> In this case the keyring contains:
>
> pub rsa4096/38DBBDC86092693E 2011-09-23 [SC]
> 647F28654894E3BD457199BE38DBBDC86092693E
> uid [ unknown] Greg Kroah-Hartman (Linux kernel stable release signing key) <greg at kroah.com>
> sub rsa4096/F38153E276D54749 2011-09-23 [E]
>
> pub rsa2048/79BE3E4300411886 2011-09-20 [SC]
> ABAF11C65A2970B130ABE3C479BE3E4300411886
> uid [ unknown] Linus Torvalds <torvalds at linux-foundation.org>
> sub rsa2048/88BCE80F012F54CA 2011-09-20 [E]
>
> pub rsa4096/E7BFC8EC95861109 2009-07-12 [SC]
> AC2B29BD34A6AFDDB3F68F35E7BFC8EC95861109
> uid [ unknown] Ben Hutchings (DOB: 1977-01-11)
> uid [ unknown] Ben Hutchings <ben at decadent.org.uk>
> uid [ unknown] Ben Hutchings <benh at debian.org>
> sub rsa4096/CF0469521357C3D7 2009-07-12 [E]
>
> pub rsa4096/DEA66FF797772CDC 2012-02-09 [SC]
> E27E5D8A3403A2EF66873BBCDEA66FF797772CDC
> uid [ unknown] Sasha Levin <sashal at kernel.org>
> uid [ unknown] Sasha Levin <alexander.levin at microsoft.com>
> uid [ unknown] Sasha Levin <alexander.levin at verizon.com>
> uid [ unknown] Sasha Levin <sasha.levin at oracle.com>
> sub rsa4096/D0065D755EB09DBB 2012-02-09 [E]
>
> The numbers of tags accepted per ID and verifier are:
>
> ID gpgv rsopv sqopv
> -------------------------------------------------------------------
> Greg Kroah-Hartman <gregkh at linuxfoundation.org> 3683 3553 0
> Greg Kroah-Hartman <gregkh at suse.de> 36 36 0
> Linus Torvalds <torvalds at linux-foundation.org> 644 452 0
> Ben Hutchings <ben at decadent.org.uk> 137 137 68
> Sasha Levin <sashal at kernel.org> 41 41 41
> Sasha Levin <alexander.levin at microsoft.com> 4 4 4
> Sasha Levin <alexander.levin at verizon.com> 27 0 0
> Sasha Levin <sasha.levin at oracle.com> 39 0 0
>
> There is already some disagreement between gpgv and rsopv, but the large
> majority of tags are accepted by both. But sqopv rejects *all*
> signatures made by Greg or Linus, and by some of Sasha's IDs. (It also
> rejects some of mine, but it appears that those are all v3 signatures
> which I don't care about.)
These also look like either problems with the certificates themselves
or the signatures (or both):
,---
$ sq cert lint <debian/upstream/signing-key.asc
Certificate 38DBBDC86092693E is not valid under the standard policy: No binding signature at time 2025-10-16T21:49:00Z
Certificate 38DBBDC86092693E contains a User ID (Greg Kroah-Hartman (Linux kernel stable release signing key) <greg at 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 2025-10-16T21:49:00Z
Certificate 79BE3E4300411886 contains a User ID (Linus Torvalds <torvalds at 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.levin at verizon.com>) protected by SHA-1
Certificate DEA66FF797772CDC contains a User ID (Sasha Levin <sasha.levin at 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
`---
(Same with «sq inspect debian/upstream/signing-key.asc».)
Uwe (CCed) has been trying to get upstream to fix their keys, and although
multiple Linux kernel maintainers have done so, not all have, AFAIK.
For uscan I had local changes to make gpgv consider SHA1 and RIPEMD160
weak digests (like dpkg has done for a while), but didn't push them
during trixie because it was too late in the release cycle. I'll flush
those out in a bit though.
In any case, as this looks like a problem with the certificates and/or
signatures, I think this report should be closed.
Thanks,
Guillem
More information about the Pkg-rust-maintainers
mailing list