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 [5] 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 against > 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 implementations instead. -- Yaakov Selkowitz Software Engineer - Platform Enablement Group Red Hat, Inc.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
