Skip to content

Draft: Keep FIPS provider

With shared OpenSSL >= 3, I'm encountering a core dump/assertion failure when trying to use --force-fips/--enable-fips:

$ python configure.py --shared-openssl --shared-zlib --shared-brotli --shared-libuv --shared-nghttp2 --without-corepack --openssl-use-def-ca-store --openssl-default-cipher-list=PROFILE=SYSTEM
INFO: configure completed successfully
$ make -j4
...
$ ./node --version
v21.0.0-pre
$ ./node --force-fips -p 'crypto.getFips()'
./node[495774]: ../src/node.cc:1070:std::unique_ptr<node::InitializationResultImpl> node::InitializeOncePerProcessInternal(const std::vector<std::__cxx11::basic_string<char> >&, ProcessInitializationFlags::Flags): Assertion `crypto::CSPRNG(nullptr, 0).is_ok()' failed.
 1: 0xc0e140 node::Abort() [./node]
 2: 0xc0e1be  [./node]
 3: 0xbc7af0  [./node]
 4: 0xbc7ffc node::Start(int, char**) [./node]
 5: 0x7f7f7ba49b4a  [/lib64/libc.so.6]
 6: 0x7f7f7ba49c0b __libc_start_main [/lib64/libc.so.6]
 7: 0xb22925 _start [./node]
[1]    496569 IOT instruction (core dumped)  ./node --force-fips -p 'crypto.getFips()'

I'm on Fedora 38, openssl-libs-3.0.9-1.fc38.x86_64.


I was toying with fixing this a bit, and this PR is my WIP approach at fixing this. The first commit just turns that assertion into an error message in order to better debug what is wrong with the CSPRNG; the other makes the error go away, but I'm not sure what other impact it can have.

On the other hand, can anyone tell me why the unload is there? I would thought that when the FIPS flags are encountered, we would want to actually leave the provider in place in order to be utilized by the application, not immediately yanking it back once confirmed it can be loaded.

I also noticed that in TestFipsCrypto() loads the provider again, then leaves it loaded… 😕

I'm making it as draft for now, because I want to know more about the points above before trying to actually push the change.

Merge request reports

Loading