During the build process, openssl records an HMAC on the `fips.so` module file that gets built. Then at runtime, when attempting to load the fips provider, it verifies the integrity of the file on disk against this pre-recorded value. However, by default the ebuild process identifies that file to be `strip`-ed, which Reproducible: Always Steps to Reproduce: 1. emerge openssl-3 with USE=fips 2. configure openssl.cnf to enable the fips (and base) providers in accordance with upstream documentation 3. run `openssl list -providers` Actual Results: Only the `base` provider is listed (because the FIPS provider failed to initialize) If you run `openssl list -provider fips` it will dump more information to the terminal: # openssl list -provider fips list: unable to load provider fips Hint: use -provider-path option or OPENSSL_MODULES environment variable. 4037B5E1DA7F0000:error:1C8000D4:Provider routines:SELF_TEST_post:invalid state:providers/fips/self_test.c:262: 4037B5E1DA7F0000:error:1C8000D8:Provider routines:OSSL_provider_init_int:self test post failure:providers/fips/fipsprov.c:707: 4037B5E1DA7F0000:error:078C0105:common libcrypto routines:provider_init:init fail:crypto/provider_core.c:932:name=fips Expected Results: Both the 'fips' and 'base' providers should be listed Applying this diff to openssl-3.0.8.ebuild solves the problem: @@ -222,6 +225,8 @@ multilib_src_install() { emake DESTDIR="${D}" install_sw if use fips; then emake DESTDIR="${D}" install_fips + # Don't strip the fips module file or it will fail internal checksum self-tests + dostrip -x /usr/$(get_libdir)/ossl-modules/fips.so fi if multilib_is_native_abi; then
Seems that I stopped writing the initial description mid-sentence :) > However, by default the ebuild process identifies that file to be `strip`-ed, which ...which causes the file that gets installed to no longer match the expected MAC/checksum, which causes the FIPS provider to refuse to load at runtime.
README-FIPS.md mentions running "openssl fipsinstall" to (re)generate fipsmodule.cnf after installation. Instead of disabling stripping, we could possibly regenerate /etc/ssl/fipsmodule.cnf in pkg_preinst. Also, we should probably disable the FIPS module for non-native ABIs, or generate separate fipsmodule.cnf files for each ABI.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=76f8af3f0ac6bd939ca6c837d0bba99098ac6ce0 commit 76f8af3f0ac6bd939ca6c837d0bba99098ac6ce0 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2023-03-11 05:50:36 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2023-03-11 16:51:01 +0000 dev-libs/openssl: generate fipsmodule.cnf in pkg_preinst This file contains an hash of the fips.so module, which may change after src_install due to automatic stripping by the package manager. README-FIPS.md says this file should be generated on each machine separately anyway. This will fail when cross-compiling since we call openssl from ${D}, but I don't see a better way to handle it. Only the primary ABI is handled currently: by the time we get to pkg_preinst, the tools from the secondary ABIs have been clobbered. Closes: https://bugs.gentoo.org/900625 Signed-off-by: Mike Gilbert <floppym@gentoo.org> .../{openssl-3.0.8.ebuild => openssl-3.0.8-r1.ebuild} | 13 +++++++++++++ 1 file changed, 13 insertions(+)
Confirmed, the fips module in this new build loads just fine. Thanks!
