On Thu, Jan 23, 2025 at 11:40:04PM -0800, Joel Ray Holveck wrote: > Package: apt > Version: 2.9.23 > Followup-For: Bug #1088288 > > 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) <supp...@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... -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
