Conflict with FIPS compliance?

[dralley]

Hello, so, I have a package which contains native code. This native code links against openssl, which then gets bundled into the package because of manylinux. It turns out that in a FIPS-enabled environment, openssl is required to perform an integrity check on itself, usually using some kind of HMAC scheme.

This check fails, which causes the loading of this package on a FIPS-enabled system to trigger a fatal error.

crypto/fips/fips.c:154: OpenSSL internal error: FATAL FIPS SELFTEST FAILURE

Now, one potential issue here is that manylinux isn't bundling the HMAC files alongside the bundled openssl, so maybe that's the reason it's failing. On the other hand, if manylinux is modifying the bundled library in any way, it might not be possible for this to work. I know manylinux does some ELF patching, but I'm not certain whether that includes the libraries that get bundled.

In either case, is there something that can be done about this?

[dralley]

Then again, maybe it's not even possible to move these files and remain FIPS compliant: openssl/openssl#25708

So I'm open to the possibility that you just cannot use bundled / manylinux packages with FIPS, and users would need to compile our package from source on the target machine so that it uses the native system crypto libraries.

[mayeut]

The bundling of shared objects is done by auditwheel. ELF files will be patched by this tool and will modify OpenSSL (all libraries that are being grafted by auditwheel are patched).
I don't know if it's possible to achieve this.