Description of problem: The FESCo-requested "stay" (https://pagure.io/fesco/issue/2960) to temporarily allow SHA1 in the RPM context for Fedora 38 seems to still be in effect: This should have been removed in Fedora 39+, but it is still present in git HEAD today: https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/blob/master/policies/DEFAULT.pol#L87 Version-Release number of selected component (if applicable): Confirmed in crypto-policies-20241029-1.git8baf557.fc41.noarch. How reproducible: Always. Steps to Reproduce: 1. Check contents of the rpm-sequoia crypto policy. 2. Check values of sha1.collision_resistance and sha1.second_preimage_resistance settings. Actual results: They are enabled. Expected results: They should be disabled. Additional info: N/A
So what's the expected course of action now? Do you want us to just drop that in rawhide, or do you want another system wide change proposal for this change?
Well, putting the restrictions on SHA-1 back was already approved by FESCo for Fedora 39 ... I'd say announce it on the "devel" list and make the change for Rawhide / F42+. Doing it in already released versions doesn't seem like a good idea.
I was about to do that, but I've run some tests beforehand and I've discovered that Chrome still isn't installable, which is tracked in bz2241019. Sorry, I don't think we can land this without RPM first learning to use the right signature.
To clarify, the issue tracked in bug 2241019 is a dnf, not rpm thing. I even pointed out a simple fix to it in 2023. Of course since then, we've moved on to dnf5, and I don't know whether it uses the same logic in that place or if it has some other related problems.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.