It's a bit unclear to me what that test is actually supposed to be doing, but these parts are highly problematic:
#: multistage :file:`Dockerfile` that builds the program from
#: :py:const:`FIPS_TEST_DOT_C` using gcc and copies it, ``libcrypto``, ``libssl``
#: and ``libz`` into the deployment image. The libraries must be copied, as they
#: are not available in the minimal container images.
...
COPY --from=builder /usr/lib64/libcrypto.so.1.1 /usr/lib64/
COPY --from=builder /usr/lib64/libssl.so.1.1 /usr/lib64/
COPY --from=builder /usr/lib64/engines-1.1 /usr/lib64/engines-1.1
COPY --from=builder /usr/lib64/.libcrypto.so.1.1.hmac /usr/lib64/
COPY --from=builder /usr/lib64/.libssl.so.1.1.hmac /usr/lib64/
note the hardcoding of the openssl so names and directories that does not work for openssl 3.x
also the fips-test.c itself is not prepared for openssl 3.x, it should test whether the default provider is disabled in fips mode and the fips provider can be initialized and the like.
imho rather than the copying hack we should imho simply not test on minimal/micro images that do not provide the right openssl library, but I can't distill from the commit messages on why this was hacked in that way in the first place.
It's a bit unclear to me what that test is actually supposed to be doing, but these parts are highly problematic:
note the hardcoding of the openssl so names and directories that does not work for openssl 3.x
also the fips-test.c itself is not prepared for openssl 3.x, it should test whether the default provider is disabled in fips mode and the fips provider can be initialized and the like.
imho rather than the copying hack we should imho simply not test on minimal/micro images that do not provide the right openssl library, but I can't distill from the commit messages on why this was hacked in that way in the first place.