musl libc with libxcrypt as crypt provider

musl libc with libxcrypt as crypt provider

[Michael Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 830 bytes --]

In line with the eventual removal of 'libcrypt' and 'crypt.h' from
glibc[0], Gentoo linux, following in the footsteps of Fedora[1], has been
evaluating using libxcrypt[2] as provider of libcrypt.so* and the crypt.h
header (see [3]). As the distro continues, and is increasing in interest
with musl-libc, we have been trying to work out how best to integrate the
new libxcrypt with musl without file collisions, as it's not (yet) apparent
how to disable the built-in crypt.h within musl. Has the musl team
considered possibl compatibility with libxcrypt moving forwards yet?

[0] https://sourceware.org/ml/libc-alpha/2017-08/msg01257.html
[1]
https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
[2] https://github.com/besser82/libxcrypt
[3] https://bugs.gentoo.org/show_bug.cgi?id=699422



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: musl libc with libxcrypt as crypt provider

[Rich Felker]

On Fri, Nov 08, 2019 at 06:59:19PM +0000, Michael Everitt wrote:
> In line with the eventual removal of 'libcrypt' and 'crypt.h' from
> glibc[0], Gentoo linux, following in the footsteps of Fedora[1], has been
> evaluating using libxcrypt[2] as provider of libcrypt.so* and the crypt.h
> header (see [3]). As the distro continues, and is increasing in interest
> with musl-libc, we have been trying to work out how best to integrate the
> new libxcrypt with musl without file collisions, as it's not (yet) apparent
> how to disable the built-in crypt.h within musl. Has the musl team
> considered possibl compatibility with libxcrypt moving forwards yet?
> 
> [0] https://sourceware.org/ml/libc-alpha/2017-08/msg01257.html
> [1]
> https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
> [2] https://github.com/besser82/libxcrypt
> [3] https://bugs.gentoo.org/show_bug.cgi?id=699422

This was raised on #musl a day or two ago, and I have some concerns,
some of which may be unfounded. Is the idea of libxcrypt to repeat the
mistake of dynamically loading backends into every process that uses
the interface, the same way nss, pam, etc. did? If so, that's really
harmful to application stability, security, etc. Even if not, I really
doubt projects like Busybox will like being told to link to a new
third-party library for basic functionality.

A few years back I looked at supporting password hashes that were "too
big" to put in libc crypt, like scrypt or yescrypt with giant roms,
and my conclusion was that the right way to do it was probably to make
crypt[_r] interface with a daemon providing the service for setting
codes it doesn't internally recognize.

I never really went anywhere with this since use of unix account login
passwords (vs ssh with pubkey) is kinda outdated to begin with, and it
wasn't clear that other applications would be using the crypt[_r] API
for this anyway.

Anyway, if you do want to use libxcrypt in a distro, I don't think any
particular measures are needed for compatibility. You can just not
install the musl crypt.h. Linking libxcrypt should automatically cause
it to get used instead of the functions in libc.

One thing to look out for is whether libxcrypt insists on having a
large crypt_data structure. If so, existing applications built with
against musl's crypt.h might be unsafe to run with it loaded in place
of crypt[_r]. This should not be an issue, since the structure should
only store the output hash, not any working state, but historical
implementations got this wrong and it's bad for both security and
memory usage.

Rich