René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"libxcrypt dependency is not FIPS compliant","articleBody":"**Feature or enhancement**\r\n\r\nPython v3.9 introduced a dependency on [libxcrypt](https://github.com/besser82/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.\r\n\r\nAs mentioned in https://github.com/besser82/libxcrypt/blob/564fa1d92379b0ccad7e7813e1c3b0eb3eee7294/README.md#compatibility-notes:\r\n\r\n\u003e 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.\r\n\r\nBelow 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):\r\n\r\n```\r\n[stanhu@stanhu-fips1 lib64]$ ldd /usr/bin/python3.6\r\n\tlinux-vdso.so.1 (0x00007ffd75f8a000)\r\n\tlibcrypto.so.1.1 =\u003e /lib64/libcrypto.so.1.1 (0x00007f5c731a6000)\r\n\tlibpython3.6m.so.1.0 =\u003e /lib64/libpython3.6m.so.1.0 (0x00007f5c72c63000)\r\n\tlibpthread.so.0 =\u003e /lib64/libpthread.so.0 (0x00007f5c72a43000)\r\n\tlibdl.so.2 =\u003e /lib64/libdl.so.2 (0x00007f5c7283f000)\r\n\tlibutil.so.1 =\u003e /lib64/libutil.so.1 (0x00007f5c7263b000)\r\n\tlibm.so.6 =\u003e /lib64/libm.so.6 (0x00007f5c722b9000)\r\n\tlibc.so.6 =\u003e /lib64/libc.so.6 (0x00007f5c71ef4000)\r\n\tlibz.so.1 =\u003e /lib64/libz.so.1 (0x00007f5c71cdc000)\r\n\t/lib64/ld-linux-x86-64.so.2 (0x00007f5c73892000)\r\n[stanhu@stanhu-fips1 lib64]$ ldd /usr/bin/python3.9\r\n\tlinux-vdso.so.1 (0x00007ffe839f5000)\r\n\tlibcrypto.so.1.1 =\u003e /lib64/libcrypto.so.1.1 (0x00007fb67781d000)\r\n\tlibpython3.9.so.1.0 =\u003e /lib64/libpython3.9.so.1.0 (0x00007fb677252000)\r\n\tlibcrypt.so.1 =\u003e /lib64/libcrypt.so.1 (0x00007fb677029000)\r\n\tlibpthread.so.0 =\u003e /lib64/libpthread.so.0 (0x00007fb676e09000)\r\n\tlibdl.so.2 =\u003e /lib64/libdl.so.2 (0x00007fb676c05000)\r\n\tlibutil.so.1 =\u003e /lib64/libutil.so.1 (0x00007fb676a01000)\r\n\tlibm.so.6 =\u003e /lib64/libm.so.6 (0x00007fb67667f000)\r\n\tlibc.so.6 =\u003e /lib64/libc.so.6 (0x00007fb6762ba000)\r\n\tlibz.so.1 =\u003e /lib64/libz.so.1 (0x00007fb6760a2000)\r\n\t/lib64/ld-linux-x86-64.so.2 (0x00007fb677f08000)\r\n```\r\n\r\nWhile Python v3.9 still works, our internal audit flagged `libxcrypt` as a possible issue.\r\n\r\n**Pitch**\r\n\r\nSince Python 3.9 may not be FIPS-compliant, it cannot technically be used on US Government systems that requires this hardening.\r\n\r\n**Previous discussion**\r\n\r\nThis dependency may have been introduced in November 2021 via https://github.com/python/cpython/pull/29725.\r\n\r\nYears ago someone raised an issue about using a FIPS-validated kernel user space API with `libxcrypt`, but this discussion seems to have gone dormant: https://github.com/besser82/libxcrypt/issues/1\r\n","author":{"url":"https://github.com/stanhu","@type":"Person","name":"stanhu"},"datePublished":"2022-05-03T16:47:46.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/92238/cpython/issues/92238"}