Description of problem: RPM, as a consumer of the libimaevm API, uses SHA256 as the digest algorithm for IMA file signatures, however there's a bug in libimaevm.c where the algorithm passed to sign_hash_v2() isn't respected and the default one (SHA1) is used instead, causing a silent failure later. This has been fixed upstream: https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/309d3369bb52179cbdb11760c0b006932a42b52f/ It also should be fixed by applying the following patch alone, however it's arguably not a proper fix as it only changes the default algorithm to SHA256 internally: https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/3328f6efed7621ae30c4da08a0cecf7630e48805/ These patches are included in v1.4 which is shipped in F36 but F35 only ships v1.3 so that one is affected. This issue was originally reported in the RPM upstream repo: https://github.com/rpm-software-management/rpm/issues/2124 Version-Release number of selected component (if applicable): ima-evm-utils-1.3.2-3.fc35
Hey, hi Michal, how are you? Good to see you again :) I'll try to fix it by backporting both changes until the end of the week.
Greetings Bruno, that sounds good, thanks :)
Michal, I prepared a scratch build for you to test, would that be fine? https://koji.fedoraproject.org/koji/taskinfo?taskID=91447313 (I created the SRPM in a fedora36 machine, but the target is indeed f35) I'm applying only the patch https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/309d3369bb52179cbdb11760c0b006932a42b52f/, since applying the second one with its parent doesn't really apply well to F35 update policy, where SHA1 were still fine. Please, let me know if that works, then I can submit an update request to bodhi.
*** Bug 2107225 has been marked as a duplicate of this bug. ***
(In reply to Bruno Meneguele from comment #3) > I'm applying only the patch > https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/ > 309d3369bb52179cbdb11760c0b006932a42b52f/, > since applying the second one with its parent doesn't really apply well to > F35 update policy, where SHA1 were still fine. Oh yup, makes sense! > Please, let me know if that works, then I can submit an update request to > bodhi. I've tried this briefly and hashes are correctly reported in the output: hash(sha256): 08a09f7b8668b6df35bac31c324b5eae09a6e78de9c6466439634c383b70a326 From which I assume the internal logic now works correctly, too. Feel free to proceed with the update!
FEDORA-2022-cd0501fc8f has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-cd0501fc8f
Michal, would you mind adding a +1 in the update request at https://bodhi.fedoraproject.org/updates/FEDORA-2022-cd0501fc8f ? Many thanks!
FEDORA-2022-cd0501fc8f has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-cd0501fc8f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-cd0501fc8f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-cd0501fc8f has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days