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

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 1 Jun 2017, Florian Weimer 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.

(Some of) the interfaces are POSIX interfaces, declared (per POSIX) in 
unistd.h, although that's only indicative of possible glibc suitability 
(after all, we don't implement ndbm.h, and XFAIL the relevant conform/ 
tests; it's left to other libraries to implement those interfaces).

Using OpenSSL in a crypt implementation does of course bring in the same 
namespace issues as with NSS modules linked with external libraries.

I have wondered if there should be a system for crypt loading .so files 
for hash algorithms, so they could be built independently of glibc, but no 
doubt building ABI-compatible libcrypt (complete with the right 
architecture-specific symbol versions) from separate sources would be 
simpler.

-- 
Joseph S. Myers
joseph@codesourcery.com