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.
Dear Maintainer,
The addition of default-sequoia.config has helped, but seems to be
incomplete. Slack still cannot be updated. It gives this error message:
Get:2 https://packagecloud.io/slacktechnologies/slack/debian jessie
InRelease [29.1 kB]
Err:2 https://packagecloud.io/slacktechnologies/slack/debian jessie
InRelease
Sub-process /usr/bin/sqv returned an error code (1), error
message is: Signing key on DB085A08CA13B8ACB917E0F6D938EC0D038651BD is
not bound: primary key because: No binding signature at
time 2024-12-17T17:27:20Z because: Policy rejected non-revocation
signature (PositiveCertification) requiring collision resistance
because: SHA1 is not considered secure since 2013-02-01T00:00:00Z
Warning: GPG error:
https://packagecloud.io/slacktechnologies/slack/debian jessie InRelease:
Sub-process /usr/bin/sqv returned an error code (1), error message is:
Signing key on DB085A08CA13B8ACB917E0F6D938EC0D038651BD is not bound:
primary key because: No binding signature at time
2024-12-17T17:27:20Z because: Policy rejected non-revocation signature
(PositiveCertification) requiring collision resistance because: SHA1
is not considered secure since 2013-02-01T00:00:00Z
Error: The repository
'https://packagecloud.io/slacktechnologies/slack/debian jessie
InRelease' is not signed.
Notice: Updating from such a repository can't be done securely, and
is therefore disabled by default.
Notice: See apt-secure(8) manpage for repository creation and user
configuration details.
It seems that there are certain requirements regarding the signing key
that are not allowed by the default-sequoia.config that is currently put
into place.
[Analysis] To clarify some of the terminology in the error message, a
"non-revocation signature" is not one that asserts the key hasn't been
revoked; it's just any signature that is not a revocation signature.
The PositiveCertification is a signature associating a user ID with the
primary key.
[Analysis] In
https://docs.rs/sequoia-openpgp/1.21.2/sequoia_openpgp/policy/enum.HashAlgoSecurity.html#variants
, note that the signature binding the user ID to the primary key need
only be second preimage resistant if the user ID is a short email
address. The Slack user ID is
"https://packagecloud.io/slacktechnologies/slack
(https://packagecloud.io/docs#gpg_signing) <support@packagecloud.io>",
which is an allowable email address format, but is not short: the cutoff
is 96 bytes, according to
https://gitlab.com/sequoia-pgp/sequoia/-/blob/93dcddcb5c5a493faa1d958a085f55d7d1eda50c/openpgp/src/packet/userid.rs#L762
. spv then falls back to requiring general collision resistance.
I was able to work around this issue by creating the following
/etc/crypto-policies/back-ends/apt-sequoia.config :
[hash_algorithms]
sha1.second_preimage_resistance = 2026-01-01
sha1.collision_resistance = 2026-01-01
[packets]
signature.v3 = 2026-01-01
If it is desirable to support such keys using SHA-1, then I suggest
putting this additional sha1.collision_resistance field in
default-sequoia.config.
No I am sorry, this is a very significant security issue if you go start trusting SHA-1 signatures. Because you don't just trust it for keys now; but for data signatures too. We haven't trusted them for data signatures since November 2016...
That makes sense. That said, do you know of a way to configure sqv to accept SHA-1 for keys?
Hi Joel, https://packagecloud.io/slacktechnologies/slack/debian jessie https://packagecloud.io/slacktechnologies/slack/debian jessie is InRelease: is: signature SHA1 and user For what it's worth, I have a (private) open ticket with Slack technical support about this issue since 10th Jan and am following-up regularly. I will reply here if this is any follow-up. Thanks! Chris
Hey Chris, Any updates on your private slack ticket? On Sat, 15 Feb 2025 22:10:33 +0000 Christopher Obbard <obbardc@debian.org> wrote: <joelh@piquan.org> at bound: securely,
Hi, The last update I had from Slack was in Feb: I have pinged them again for an update. For now, I use the flatpak package... Cheers! Chris