Date: Fri, 8 Nov 2019 14:13:44 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: musl libc with libxcrypt as crypt provider 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, Gentoo linux, following in the footsteps of Fedora, has been > evaluating using libxcrypt as provider of libcrypt.so* and the crypt.h > header (see ). 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? > >  https://sourceware.org/ml/libc-alpha/2017-08/msg01257.html >  > https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt >  https://github.com/besser82/libxcrypt >  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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.