I've seen this question enough times recently to decide to just write up a blog post on it and point people here. :)
If you are running Fedora 38 (currently rawhide, but will be branching off soon) and you are getting errors like this from dnf and/or rpm:
Running transaction check error: rpmdbNextIterator: skipping h# 47749 Header V4 DSA/SHA1 Signature, key ID 7fac5991: BAD Header SHA256 digest: OK Header SHA1 digest: OK error: rpmdbNextIterator: skipping h# 47749 Header V4 DSA/SHA1 Signature, key ID 7fac5991: BAD Header SHA256 digest: OK Header SHA1 digest: OK
This post is for you. What is going on here? And how can you get around the problem?
Well, what happened is that rpm used to have internal code to handle signatures on packages. This code was really something rpm didn’t want to have to maintain, so they switched recently to using sequoia, which is a new gnupg handling project written in rust. With this switch, sequoia actually honors the site wide fedora crypto policy (which the internal old rpm version did not).
Back in Fedora 33, the distro wide crypto policy was updated to disallow SHA-1 as a signature algorithm. See https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 for more information.
You might wonder why, if Fedora changed the distro wide crypto policy to disallow SHA-1 in signatures, why didn’t they update things so nothing used SHA-1 now? Well, the short answer is: they did. No rpms that Fedora produces now use SHA-1 signatures. However, some third-party rpms do. One of the big ones that many people are hitting is google’s “chrome” web browser. There’s probably others.
Now that we know _why_ this is happening, what can you do? Well, first you need to do something so dnf and rpm allows you to remove/update/change your package set. You can do this by (temporarily!) allowing SHA-1 Signatures with:
sudo update-crypto-policies --set DEFAULT:SHA1
rpm and dnf should now work for you again. You might remove packages that have SHA-1 signatures and switch to alternatives. Or wait until google updates their signing key (the current one is from 2007). Once you have done what you need to do you can set the policy back to it’s sane default:
sudo update-crypto-policies --set DEFAULT