On 2017-11-08 11:08, Björn 'besser82' Esser wrote:
since there has been some discussion in the last time about removing
libcrypt from glibc in some time [1,2,3,4] and splitting it out into a
separate project which can evolve quicker, I'd like to hear your
oppinion about replacing glibc's libcrypt with libxcrypt  for Fedora
29 (or 30).
Is anyone besides us (committed to) using and contributing to libxcrypt?
libxcrypt will be fully binary compatible with software linked
glibc's libcrypt and does not require any rebuilds. However, the
converse is not true: programs linked against libxcrypt will not work
with glibc's libcrypt. It comes with a set of extended interfaces
pioneered by Openwall Linux, crypt_rn, crypt_ra, crypt_gensalt,
crypt_gensalt_rn, and crypt_gensalt_ra. Also, programs that use
certain legacy APIs supplied by glibc's libcrypt (encrypt, encrypt_r,
setkey, setkey_r, and fcrypt) cannot be compiled against libxcrypt.
While splitting things out of glibc is overall probably a good thing --
IMO the ecosystem has generally benefited from libtirpc -- in this case
the proposed removal method concerns me:
* crypt(3)'s declaration is in unistd.h according to SUS. While a
duplicate declaration has been in crypt.h for some time,
standards-conforming software can reasonably rely on the former. The
glibc crypt removal proposal included an outright removal of this
declaration, along with _XOPEN_CRYPT, which would leave no way for
libxcrypt to fulfill the standard. Instead, if at least GCC 5 can be
assumed, they should be made conditional on __has_include(<crypt.h>).
* encrypt and setkey, while noted in the Future Directions as subject to
future obsoletion or removal, is still not even officially obsolete in
SUSv4. This plan seems to leave no way whatsoever to compile software
which depends on these still-standardized calls.
* Has a rebuild of all libcrypt dependent packages been made with
libxcrypt-devel, with a careful analysis of the resulting binaries to
assure that they still have the exact same symbol dependencies on
libcrypt as they do when built with glibc's? I'm concerned that e.g.
configure test failures caused by re/moved declarations would cause
features to be quietly disabled, or software to use their own bundled
Software Engineer - Platform Enablement Group
Red Hat, Inc.