libxcrypt dependency is not FIPS compliant

[stanhu]

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

[encukou]

libxcrypt is only needed for the crypt module, which is deprecated and scheduled for removal in Python 3.13.
Feel free to build without it: if libxcrypt is not found by configure, Python should build successfully (but the crypt module won't be available).
If you have any issues building Python without libxcrypt please reopen (or open a new issue).

[stanhu]

@encukou Great, thank you!