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: Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 2 Jun 2017 08:18:34 +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 C2431793EF
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C2431793EF
- References: <79469eab-c809-a5b8-3297-2536320a834d@gmail.com> <CAKCAbMiRUozNA9UF5R0=8+-Gt9ShPBtMvFyxTswazu+q1J5kpw@mail.gmail.com> <8dcc3319-0ad0-5359-0ba2-d79e4edc317e@redhat.com> <CAKCAbMhhFcWZG0U712=ZPSfEs8eE1xa79qsL0G--EQi-O=YGkQ@mail.gmail.com>
On 06/01/2017 08:59 PM, Zack Weinberg wrote:
> 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.
Yes, at least until we implement arc4random.
Florian