`osxcross-macports` script fails to verify ripemd-160 signatures with OpenSSL 3.x (On Fedora 36)

[ProjectSynchro]

This can be worked around by adding -provider legacy to the offending invocations of openssl. I patch the script in my builder Dockerfile with:

sed -i 's/\bopenssl rmd160\b/openssl rmd160 -provider legacy/g' $(command -v osxcross-macports)
sed -i 's/\bopenssl dgst -ripemd160 -verify\b/openssl dgst -provider default -provider legacy -ripemd160 -verify/g' $(command -v osxcross-macports)

I do not know how backwards compatible this is, so the script might need a function to check the openssl version, and pass the provider flags if OpenSSL 3.x is used.

[nephatrine]

I was running into this issue on Ubuntu Jammy (LTS) as well and this fix worked great for me too.

[mite-user]

https://www.openssl.org/blog/blog/2022/10/18/rmd160-and-the-legacy-provider/

https://github.com/openssl/openssl/pull/19375 Changes from the pull request were merged despite being marked as "closed".

https://github.com/openssl/openssl/blob/master/CHANGES.md#changes-between-306-and-307-1-nov-2022 "Added RIPEMD160 to the default provider."

rmd160 is available in openssl 3.0.7+ without the -provider legacy.

openssl versions

https://packages.fedoraproject.org/pkgs/openssl/openssl/ 3.0.2 on fedora 36 and 3.0.5 on fedora 37

https://packages.debian.org/search?searchon=names&keywords=openssl 3.0.7 on debian 12

https://packages.ubuntu.com/search?keywords=openssl 3.0.2 on Ubuntu 22.04 and 3.0.5 on Ubuntu 22.10

So the problem still exists but will probably disappear soon.

[ProjectSynchro]

Sweet, that's nice to see.

Definitely a big whoopsie on OpenSSL's side: https://www.openssl.org/blog/blog/2022/10/18/rmd160-and-the-legacy-provider/