Change Details

Distros have been dropping glibc's libcrypt in favour of [libxcrypt](https://github.com/besser82/libxcrypt/) which features backwards compatibility for glibc. Mostly it seems to be wanting a more agile library not tied to glibc that supports modern hashing techniques (`yescrypt`). In glibc 2.28's [release notes](https://sourceware.org/legacy-ml/libc-alpha/2018-08/msg00003.html) glibc mention wanting to hand off maintenance of libcrypt > Quoted Text * We have tentative plans to hand off maintenance of the passphrase-hashing library, libcrypt, to a separate development project that will, we hope, keep up better with new passphrase-hashing algorithms. We will continue to declare 'crypt' in <unistd.h>, and programs that use 'crypt' or 'crypt_r' should not need to change at all; however, distributions will need to install <crypt.h> and libcrypt from a separate project. > Quoted Text * In this release, if the configure option --disable-crypt is used, glibc will not install <crypt.h> or libcrypt, making room for the separate project's versions of these files. The plan is to make this the default behavior in a future release. Fedora's reasoning; https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt Arch Linux's reasoning: https://bugs.archlinux.org/task/67312 This would involve building glibc with --disable-crypt enabled. Packaging libxcrypt and then rebuilding all packages that link against `libcrypt.so`.

Distros have been dropping glibc's libcrypt in favour of [libxcrypt](https://github.com/besser82/libxcrypt/) which features backwards compatibility for glibc. Mostly it seems to be wanting a more agile library not tied to glibc that supports modern hashing techniques (`yescrypt`). In glibc 2.28's [release notes](https://sourceware.org/legacy-ml/libc-alpha/2018-08/msg00003.html) glibc mention wanting to hand off maintenance of libcrypt > Quoted Text * We have tentative plans to hand off maintenance of the passphrase-hashing library, libcrypt, to a separate development project that will, we hope, keep up better with new passphrase-hashing algorithms. We will continue to declare 'crypt' in <unistd.h>, and programs that use 'crypt' or 'crypt_r' should not need to change at all; however, distributions will need to install <crypt.h> and libcrypt from a separate project. > Quoted Text * In this release, if the configure option --disable-crypt is used, glibc will not install <crypt.h> or libcrypt, making room for the separate project's versions of these files. The plan is to make this the default behavior in a future release. Fedora's reasoning; https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt Arch Linux's reasoning: https://bugs.archlinux.org/task/67312 Debian mini-blog: https://blog.bofh.it/debian/id_458 This would involve building glibc with --disable-crypt enabled. Packaging libxcrypt and then rebuilding all packages that link against `libcrypt.so`.

Distros have been dropping glibc's libcrypt in favour of [libxcrypt](https://github.com/besser82/libxcrypt/) which features backwards compatibility for glibc. Mostly it seems to be wanting a more agile library not tied to glibc that supports modern hashing techniques (`yescrypt`). In glibc 2.28's [release notes](https://sourceware.org/legacy-ml/libc-alpha/2018-08/msg00003.html) glibc mention wanting to hand off maintenance of libcrypt > Quoted Text * We have tentative plans to hand off maintenance of the passphrase-hashing library, libcrypt, to a separate development project that will, we hope, keep up better with new passphrase-hashing algorithms. We will continue to declare 'crypt' in <unistd.h>, and programs that use 'crypt' or 'crypt_r' should not need to change at all; however, distributions will need to install <crypt.h> and libcrypt from a separate project. > Quoted Text * In this release, if the configure option --disable-crypt is used, glibc will not install <crypt.h> or libcrypt, making room for the separate project's versions of these files. The plan is to make this the default behavior in a future release. Fedora's reasoning; https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt Arch Linux's reasoning: https://bugs.archlinux.org/task/67312 Debian mini-blog: https://blog.bofh.it/debian/id_458 This would involve building glibc with --disable-crypt enabled. Packaging libxcrypt and then rebuilding all packages that link against `libcrypt.so`.