Doing a "dnf reinstall bash" in parallel to a (long) list of RPMs to check, gives: (example) /mnt/lager/fedora/linux/releases/43/Everything/x86_64/os/Packages/a/asterisk-sounds-core-en_AU-gsm-1.6.1-20.fc43.noarch.rpm: digests SIGNATURES NOT OK Reproducible: Sometimes Steps to Reproduce: 1. Make a local copy of .../releases/43/Everything/x86_64/os/Packages/*/*.rpm 2. Checking this copy with: find .../release/43/Everything/x86_64/os/Packages-name "*.rpm" | xargs rpm --checksig | grep -v "digests signatures OK" 3. While 2. is still running start in a second terminal dnf reinstall bash Actual Results: Some lines with "digests SIGNATURES NOT OK" Expected Results: No output
Do the signatures actually check out if that parallel 'dnf reinstall bash' is not done? Is the find/checksig command run as a regular user or root? What errors is the signature checking getting (try adding -v to the --checksig command)
Yes, all signatures are OK without 'dnf reinstall bash'. find/checksig is done as regular user, dnf as root. I am still trying to reproduce this with rpm --checksig -v
I get the following with -v: OK run: ./g/golang-github-elithrar-simple-scrypt-devel-1.3.0-23.fc43.noarch.rpm: Header OpenPGP V4 RSA/SHA256 signature, key fingerprint: c6e7f081cf80e13146676e88829b606631645531: OK Header SHA256 digest: OK Payload SHA256 digest: OK Not OK run: (with parallel dnf reinstall): ./g/golang-github-elithrar-simple-scrypt-devel-1.3.0-23.fc43.noarch.rpm: Header OpenPGP V4 RSA/SHA256 signature, key ID 829b606631645531: NOKEY Header SHA256 digest: OK Payload SHA256 digest: OK It seem this problem is only sporadic.
Right. This would be related to transaction and/or database locking. The reinstall needs an exclusive lock for a while, and a regular user doesn't have the permission to do db-level locking so there's always going to be issues with concurrent user queries. But in this case I suspect it's the transaction lock which the keyring read momentarily grabs, and getting that will fail while the reinstall transaction is in progress. So whenever xargs decides to spin a new rpm command, there's a race with the reinstall process. The keyring read should arguably wait for the lock instead of just giving up and failing (there should be an error message about this somewhere in your output), but this case probably runs into the heuristic that it only waits for the lock on interactive use (when stdin is a tty, which it isn't here). So there's a bug (or a few) in there quite clearly, what we can do about it is less clear. Thanks for the report though. I'll move this ticket upstream because this is not Fedora specific.
Thank you very much for your effort. Looking forward what upstream will tell about this issue.
I'm the upstream devel lead, so see above :D