This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC][PATCH][BZ 2100] blowfish support in libcrypt
- From: Florian Weimer <fweimer at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Thu, 1 Jun 2017 20:52:32 +0200
- Subject: Re: [RFC][PATCH][BZ 2100] blowfish support in libcrypt
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com B82B27AE85
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B82B27AE85
- References: <79469eab-c809-a5b8-3297-2536320a834d@gmail.com> <CAKCAbMiRUozNA9UF5R0=8+-Gt9ShPBtMvFyxTswazu+q1J5kpw@mail.gmail.com>
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.
Thanks,
Florian