On 11/09/2017 02:26 AM, Yaakov Selkowitz wrote:
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?
Doesn't matter IMHO because libcrypt-nss is essentially our very own
special snowflake, too.
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>).
I think we can keep crypt at least in Fedora's <unistd.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.
But these calls are truly obsolete. We can't change them from 56-bit
DES in glibc for backwards compatibility reasons, and applications
really should not use DES anymore.
Thanks,
Florian
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
