This is the mail archive of the
mailing list for the glibc project.
Re: [RFC][PATCH][BZ 2100] blowfish support in libcrypt
- From: Zack Weinberg <zackw at panix dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 1 Jun 2017 14:59:44 -0400
- Subject: Re: [RFC][PATCH][BZ 2100] blowfish support in libcrypt
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <CAKCAbMiRUozNA9UF5R0=8+-Gt9ShPBtMvFyxTswazu+q1J5kpw@mail.gmail.com> <email@example.com>
On Thu, Jun 1, 2017 at 2:52 PM, Florian Weimer <firstname.lastname@example.org> 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 ;-)