Description
Feature or enhancement
Python v3.9 introduced a dependency on libxcrypt, which does not appear to be FIPS compliant. This may raise compliance questions for those who have depended on Python using a FIPS-validated OpenSSL in the past.
As mentioned in https://github.com/besser82/libxcrypt/blob/564fa1d92379b0ccad7e7813e1c3b0eb3eee7294/README.md#compatibility-notes:
glibc’s libcrypt could optionally be configured to use Mozilla’s NSS library’s implementations of the cryptographic primitives md5crypt, sha256crypt, and sha512crypt. This option is not available in libxcrypt, because we do not currently believe it is a desirable option. The stated rationale for the option was to source all cryptographic primitives from a library that has undergone FIPS certification, but we believe FIPS certification would need to cover all of libxcrypt itself to have any meaningful value. Moreover, the strongest hashing methods, yescrypt and bcrypt, use cryptographic primitives that are not available from NSS, so the certification would not cover any part of what will hopefully be the most used code paths.
Below is the output from Red Hat Linux 8 in FIPS mode. Note the introduction of libcrypt.so.1 (which is provided by the libxcrypt package):
[stanhu@stanhu-fips1 lib64]$ ldd /usr/bin/python3.6
linux-vdso.so.1 (0x00007ffd75f8a000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f5c731a6000)
libpython3.6m.so.1.0 => /lib64/libpython3.6m.so.1.0 (0x00007f5c72c63000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5c72a43000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f5c7283f000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f5c7263b000)
libm.so.6 => /lib64/libm.so.6 (0x00007f5c722b9000)
libc.so.6 => /lib64/libc.so.6 (0x00007f5c71ef4000)
libz.so.1 => /lib64/libz.so.1 (0x00007f5c71cdc000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5c73892000)
[stanhu@stanhu-fips1 lib64]$ ldd /usr/bin/python3.9
linux-vdso.so.1 (0x00007ffe839f5000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fb67781d000)
libpython3.9.so.1.0 => /lib64/libpython3.9.so.1.0 (0x00007fb677252000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fb677029000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb676e09000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb676c05000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007fb676a01000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb67667f000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb6762ba000)
libz.so.1 => /lib64/libz.so.1 (0x00007fb6760a2000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb677f08000)
While Python v3.9 still works, our internal audit flagged libxcrypt as a possible issue.
Pitch
Since Python 3.9 may not be FIPS-compliant, it cannot technically be used on US Government systems that requires this hardening.
Previous discussion
This dependency may have been introduced in November 2021 via #29725.
Years ago someone raised an issue about using a FIPS-validated kernel user space API with libxcrypt, but this discussion seems to have gone dormant: besser82/libxcrypt#1