[RFC][PATCH][BZ 2100] blowfish support in libcrypt

[Björn Esser]

Am 01.06.2017 um 20:59 schrieb Zack Weinberg:
> 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.
>
> I wouldn't want to do this without having maintainers lined up for the
> independent libcrypt, though (and no, I'm not volunteering ;-)
>
> zw

There is libxcrypt [1] 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?