Bug 1847529

(In reply to Andrew Mike from comment #0)
> - nodejs in UBI 8 FIPS Mode should not return an unimplemented error when
> running with '--enable-fips' or '--force-fips' options.

Andrew, do you think you can get clarification on this? What does it mean "unimplemented error". Trying just simple test cases, this is my experience:

~~~
$ node --enable-fips
node: bad option: --enable-fips

$ node --force-fips
node: bad option: --force-fips
~~~

So where comes the "unimplemented error" from.

> - nodejs should start and function in an Openshift 4.x environment that is
> enabled for FIPS.

I am quite sure it does start and function already. If it does not, then I would appreciate more details.

Just to be clear, if system is FIPS enabled, it does not matter if the '--enable-fips' or '--force-fips' are used, supported or not. Node.js will use just FIPS certified functionality provided by system OpenSSL. You can find more details at https://access.redhat.com/articles/3655361.

Also, I wonder what is the output of following command:

~~~
$ node -p 'crypto.getFips()'
~~~

which should tell us if the FIPS mode is (system wide) enabled, no matter if the `--{enable,force}-fips` flags were used.

From the container:

[kubeadmin@watson-ocp-4-fips-inf ~]$ node -p 'crypto.getFips()'
0

[kubeadmin@watson-ocp-4-fips-inf ~]$ cat /proc/sys/crypto/fips_enabled
0

From the same worker:

[core@worker0 ~]$ sysctl crypto.fips_enabled
crypto.fips_enabled = 1
[core@worker0 ~]$ cat /proc/sys/crypto/fips_enabled
1

Thank you Aaron.

It seems the FIPS is not enabled for the container. Could you please double check, that you have followed this guide?

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/security_hardening/index#enabling-fips-mode-in-a-container_using-the-system-wide-cryptographic-policies

Namely, I am interested in comparison of `cat /etc/system-fips` and `update-crypto-policies --show` on the host and on the container.

I am trying to get the information you all were asking for and will follow up.

Looking into this, I believe that Node.js is unnecessarily providing misleading information, which depends on build configuration, while the system configuration might be different. I have opened this upstream ticket which could help to address this issue:

https://github.com/nodejs/node/issues/34903

All the trackers are now MODIFIED, and the fix should be shipped in the appropriate release. Closing this as NEXTRELEASE, please follow the individual trackers for future work.