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: Björn Esser <bjoern dot esser at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 1 Jun 2017 15:14:38 -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>
On Thu, Jun 1, 2017 at 2:44 PM, Zack Weinberg <email@example.com> wrote:
> Here are some high-level comments; I have not reviewed the code in detail.
> 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. And
> perhaps move the now-legacy-DES-only function into libc proper and
> drop libcrypt, freeing the library name for PAM or some other project
> to adopt. That would render the question of OpenWall's additional APIs
I think I should make clear that I'm proposing this as a _solution_ to
the problem of glibc being unconscionably slow to adopt modern
password hashing. glibc is very slow to do _anything_, because it's a
big sprawling library, constrained by standards and by ABI
compatibility, and because we have some nasty process problems (in a
sentence: nobody feels empowered to say "yes" to anything). And
people are understandably very cautious about upgrading it.
An independent project, focused on providing password hashing and
nothing else, should be able to work much more efficiently.