Hi! On Thu, 2025-03-20 at 08:44:21 +0000, Jonathan McDowell wrote: > On Tue, Mar 18, 2025 at 09:43:33AM +0100, Uwe Kleine-König wrote: > > On Tue, Mar 18, 2025 at 02:20:26AM +0100, Guillem Jover wrote: > > > It would be nice to stop accepting new updates that regress on this > > > front. And ideally to start a new campaign like had been done in the > > > past for other issues about weak keys/certificates. > > > > Something like this might implement the "stop accepting new updates" > > part. It's a bit more strict than suggested because it refuses all > > updates if the new key is broken. > > The other problem is that "sq cert" is not available in bookworm. We > have a requirement that we can build the keyring under a machine > running stable. Recent versions of sequoia can't even be built on > bookworm machine (they want a newer Rust compiler), so unfortunately > we're not going to be able to build that sort of check into our > pipelines until trixie is released and deployed in the right places.
I think passing «--weak-digest SHA1 --weak-digest RIPEMD160» to the relevant gpg invocations might effectively do the same (?). This has been in effect in Dpkg::* Perl modules, and thus dpkg-source for some time now as well as on things like dscverify (AFAIR), and recently on dupload as well. Otherwise in bookworm the Sequoia certificate linter was available in the form of the sq-keyring-linter package and command. > I see Guillem has already taken this to -devel. While I agree we > want to get rid of SHA-1 self-signatures on keys, I'm not clear on > exactly what problem this is causing with new dpkg, given that I'd > expect the signatures it cares about are from the unaffected role > keys? dpkg (the project) and surrounding tools are more concerned about the non-role keys than the role or archive keys, as those tools deal with signatures on .dsc, .changes and similar artifacts, signed directly by developers. I brought it up there after receiving #1100867, and realizing that an earlier report I had been pointed at (see from https://bugs.debian.org/1076223#54 onwards) was affected by the same issues, to try to mitigate similar confused reactions from developers. Thanks, Guillem
