When trying to build afterburn's RPM on fedora 38 we get a failed 'sha2::Digest' error. This is odd because this package version was building for a while without any issues. We noticed that the upstream repo's CI started to fail with little information so we then kicked off the scratch build and got the URL which demonstrates the FTBFS. We have no idea what has caused this, we can speculate that some dependency is no longer compatible but not sure which one. Reproducible: Always Steps to Reproduce: 1. procure a srpm 2. mock -r fedora-38-x86_64 --rebuild ~/workspace/rpms/upstream/rust-afterburn/rust-afterburn-5.4.2-1.fc38.src.rpm Actual Results: Fails to build from source with an error pointing to sha::Digest. Expected Results: Able to build from source RPM.
Note that the rawhide build started failing once openssh-keys was updated from v0.5 to v0.6: It looks like while upstream afterburn *claims* to be compatible with both v0.5 and v0.6, it actually isn't.
Note: The error message suggests that two different versions of the RustCrypto stack are being used, and they are not inter-compatible. Looking at the root.log of the latest koschei build, this indeed seems to be the case: - both digest 0.9 and digest 0.10 are pulled in - hmac 0.11 is pulled in instead of hmac 0.12 - sha1 0.10 is pulled in but not 0.9 - sha2 0.9 is pulled in but not 0.10 So it looks like afterburn (or one of its dependencies) needs to be updated to the newer versions of these crates - but you cannot mix-and-match.
Thank you so much for the quick feedback. Ok I will take a look at openssh-keys first.
I opened an issue with upstream openssh-keys where I tried to explain the problem and its cause: https://github.com/coreos/openssh-keys/issues/89
Ah; I think I found it. libsystemd seems to requiring >=0.10.0, >=0.11.0 via a Caret requirement. Where ssh-keys as of v0.6.1 is requiring >= 0.9, < 0.11 So I assume the best action is to just change ssh-keys to be the same as libsystemd ? And thank you so much for the issue report !
If those two are the only instance, there shouldn't be any problem, since it would resolve to only sha2 v0.10, which is compatible with both requirements. But bumping openssh-keys to both sha2 v0.10 and md-5 v0.10 would be a good first step. However, since both versions (v0.9 *and* v0.10 of sha2) end up in the dependency tree, it looks like different dependencies are pulling in different versions (possibly via hmac v0.11, which might need to be bumped to v0.12 as well), so this might end up being a required second step. > And thank you so much for the issue report ! No problem! I've dealt with similar issues before, so at least I knew what to look for when I saw the cryptic error message in the build log.
So @bgilbert just pointed out that URL which demonstrates the problem (from the fedora bug template) is not visible. So for reference this is the failing scratch build https://koji.fedoraproject.org/koji/taskinfo?taskID=102428074. I went ahead and created a pr upstream for the change in openssh-keys https://github.com/coreos/openssh-keys/pull/90.
Fixed by https://bodhi.fedoraproject.org/updates/FEDORA-2023-0f1fbda0a1.