This is the mail archive of the
mailing list for the glibc project.
Re: [RFC][PATCH][BZ 2100] blowfish support in libcrypt
- From: Björn Esser <bjoern dot esser at gmail dot com>
- To: libc-alpha at sourceware dot org
- Date: Thu, 1 Jun 2017 21:05:26 +0200
- 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> <CAKCAbMhhFcWZG0U712=ZPSfEs8eE1xa79qsL0G--EQi-O=YGkQ@mail.gmail.com>
Am 01.06.2017 um 20:59 schrieb Zack Weinberg:
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 ;-)
There is libxcrypt  around in some distros (e.g. Debian, Gentoo,
Arch, among other small ones) which would serve this approach pretty
well and already implements all my changes from this patch. I'd
volunteer to refactor this being the new libcrypt as a separate project.
During the refactoring, I can throw out all stuff being already provided
by OpenSSL and wrap those in the established crypt function.
What do you think?