Dear Maintainer, following this problem resolution: [SID - Unstable] apt getting an errsig with the microsoft repo https://forums.debian.net/viewtopic.php?t=159398 gpgv-sq fails to verify some good signatures, at least Microsoft's. How to reproduce the issue: $ wget -qP /tmp/ https://packages.microsoft.com/keys/microsoft.asc https://packages.microsoft.com/repos/edge/dists/stable/InRelease $ gpg -o /tmp/microsoft.gpg --dearmor /tmp/microsoft.asc $ gpgv-sq --keyring /tmp/microsoft.gpg /tmp/InRelease gpgv: Signature made Fri Jul 12 19:23:04 2024 +02:00 gpgv: using RSA key EB3E94ADBE1229CF gpgv: Can't check signature: Bad public key The "normal" gpgv validates the signature: $ gpgv --keyring /tmp/microsoft.gpg /tmp/InRelease gpgv: Signature made Fri 12 Jul 2024 07:23:04 PM CEST gpgv: using RSA key EB3E94ADBE1229CF gpgv: Good signature from "Microsoft (Release signing) <gpgsecurity@microsoft.com>" $ gpg -vv --show-keys /tmp/microsoft.gpg gpg: enabled compatibility flags: # off=0 ctb=99 tag=6 hlen=3 plen=269 :public key packet: version 4, algo 1, created 1446074508, expires 0 pkey[0]: [2048 bits] pkey[1]: [17 bits] keyid: EB3E94ADBE1229CF # off=272 ctb=b4 tag=13 hlen=2 plen=55 :user ID packet: "Microsoft (Release signing) <gpgsecurity@microsoft.com>" # off=329 ctb=89 tag=2 hlen=3 plen=309 :signature packet: algo 1, keyid EB3E94ADBE1229CF version 4, created 1446074508, md5len 0, sigclass 0x13 digest algo 2, begin of digest 1a 9b hashed subpkt 2 len 4 (sig created 2015-10-28) hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2) hashed subpkt 21 len 3 (pref-hash-algos: 2 8 3) hashed subpkt 22 len 2 (pref-zip-algos: 2 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (keyserver preferences: 80) subpkt 16 len 8 (issuer key ID EB3E94ADBE1229CF) data: [2047 bits] pub rsa2048 2015-10-28 [SC] BC528686B50D79E339D3721CEB3E94ADBE1229CF uid Microsoft (Release signing) <gpgsecurity@microsoft.com>
I also hit this bug, with gpgv-sq 0.10.1-1. My reproducer is similar: wget -O 0ab215679c571d1c8325275b9bdb3d89ce49ec21.asc \ 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x0ab215679c571d1c8325275b9bdb3d89ce49ec21' wget https://ppa.launchpadcontent.net/mozillateam/ppa/ubuntu/dists/oracular/InRelease gpg --no-default-keyring --keyring ./somekeyring.gpg --import 0ab215679c571d1c8325275b9bdb3d89ce49ec21.asc With gpgv from gnupg we have a good signature for 0AB21567...: $ gpgv --keyring ./somekeyring.gpg InRelease gpgv: Signature made Tue 30 Jul 2024 07:09:17 AM KST gpgv: using RSA key 738BEB9321D1AAEC13EA9391AEBDF4819BE21867 gpgv: Can't check signature: No public key gpgv: Signature made Tue 30 Jul 2024 07:09:17 AM KST gpgv: using RSA key 0AB215679C571D1C8325275B9BDB3D89CE49EC21 gpgv: Good signature from "Launchpad PPA for Mozilla Team" while with gpgv-sq: $ gpgv-sq --keyring ./somekeyring.gpg InRelease gpgv: Signature made Tue Jul 30 07:09:17 2024 +09:00 gpgv: using RSA key 738BEB9321D1AAEC13EA9391AEBDF4819BE21867 gpgv: Can't check signature: No public key gpgv: Signature made Tue Jul 30 07:09:17 2024 +09:00 gpgv: using RSA key 0AB215679C571D1C8325275B9BDB3D89CE49EC21 gpgv: Can't check signature: Bad public key I'm attaching the files needed to reproduce as above. Cheers,
Well, in my case using `gpgv-sq -vv` clarified: gpgv: Signature made Tue Jul 30 07:09:17 2024 +09:00 gpgv: using RSA key 0AB215679C571D1C8325275B9BDB3D89CE49EC21 gpgv: Can't check signature: Bad public key Signing key on 0AB215679C571D1C8325275B9BDB3D89CE49EC21 is not bound: gpgv: error: No binding signature at time 2024-07-29T22:09:17Z gpgv: because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance gpgv: because: SHA1 is not considered secure since 2023-02-01T00:00:00Z so the signature rejected because of the default policy.
control: retitle -1 gpgv-sq: fails to verify some good sha1 signatures because of default policy thanks hi, thanks for the bug report and clarifications! So I guess we should tag this bug "upstream" and "wontfix"?
control: tags -1 + upstream Hi, I tagged this bug upstream. I still hope it's not a full wontfix, as this prevents debootstrapping old Debian and Ubuntu releases, with release files signed with older (weaker) keys.
Control: clone -1 -2 Control: reassign -2 apt Control: tag -1 wontfix You can override this with a custom security policy: https://docs.rs/sequoia-policy-config/latest/sequoia_policy_config/ [hash_algorithms] sha1.second_preimage_resistance = 2026-01-01 The next version of APT will include said policy and apply it by default to give a grace period of about one year, but as for gpgv-sq, I think the default behavior makes sense.
[...] [...] for the avoidance of doubt: I agree & thanks Julian!