On Thu, Jun 1, 2017 at 2:52 PM, Florian Weimer <fweimer@redhat.com> wrote:
On 06/01/2017 08:44 PM, Zack Weinberg wrote:
First, if we were designing from scratch today, we wouldn't have
crypt(3) in the C library at all; it would make more sense to keep it
with the implementations of login(1) and passwd(1), i.e. the PAM
suite. Indeed, I see that PAM independently implements the $1$
md5-based format and something called "bigcrypt". We're stuck with
crypt(3), the function, in glibc forever because it's in POSIX, but I
have to wonder whether it might make more sense to move _all_ of the
modern password hashes into PAM and _drop_ them from glibc.
We could build an ABI-compatible version of libcrypt from a suitable
cryptographic library (probably OpenSSL) because that's where all the
algorithms live anyway (PAM doesn't have that advantage). There is
nothing glibc-specific in libcrypt, and glibc does not otherwise use it.
And libcrypt is also the only thing that cares about FIPS and NSS,
right? So there's a significant dependency-graph win if we kick it
out of the glibc source tree, as well.
I wouldn't want to do this without having maintainers lined up for the
independent libcrypt, though (and no, I'm not volunteering ;-)
zw