Breaks listing or upgrading SHA-1 RPMs [LWN.net]

Breaks listing or upgrading SHA-1 RPMs

Posted Mar 17, 2022 8:32 UTC (Thu) by rwmj (subscriber, #5474)
Parent article: Removing SHA-1 for signatures in Fedora

One thing that isn't clear about this change is that it breaks listing out and upgrading installed RPMs that are using SHA-1 signatures. So it's not only a question of whether third party repos are still using SHA-1, but whether third party repos have ever used SHA-1 signatures and those packages could still be installed.

The way around this is (and indeed any other SHA-1 related problem) is:

update-crypto-policies --set LEGACY

but this is a huge hammer, reducing security across the whole system. This might become the new "disable SELinux" which took years and years to overcome. I asked the developers to look again and see if we can make safer tools:

https://bugzilla.redhat.com/show_bug.cgi?id=2064740

For me the RPM / SHA-1 change particularly affected libguestfs which wants to analyze the RPMs in old guests (eg. RHEL < 5). We worked around it by turning off RPM signature validation, which is (arguably) bad, but it's only for examining already installed RPMs so I guess it'll be OK.

Breaks listing or upgrading SHA-1 RPMs

Posted Mar 23, 2022 6:41 UTC (Wed) by AdamW (subscriber, #48457) [Link]

IIRC it is possible to implement something more finely grained than just "pick DEFAULT or LEGACY" with the crypto-policies system, but it's more complicated and difficult. This again is similar to SELinux, where it's usually a much better idea to create a custom policy than just switch to permissive mode, but doing so is more than a single command so people just use the big hammer...