From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14918 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl libc with libxcrypt as crypt provider Date: Fri, 8 Nov 2019 14:13:44 -0500 Message-ID: <20191108191344.GH16318@brightrain.aerifal.cx> References: <22a02b7a-b753-e2e4-f92d-a7c0011866fb@2e0cer.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="3615"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14934-gllmg-musl=m.gmane.org@lists.openwall.com Fri Nov 08 20:13:59 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iT9hn-0000ox-Cg for gllmg-musl@m.gmane.org; Fri, 08 Nov 2019 20:13:59 +0100 Original-Received: (qmail 30148 invoked by uid 550); 8 Nov 2019 19:13:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 30120 invoked from network); 8 Nov 2019 19:13:56 -0000 Content-Disposition: inline In-Reply-To: <22a02b7a-b753-e2e4-f92d-a7c0011866fb@2e0cer.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14918 Archived-At: 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