From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5313 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: Re: Recommended way to probe for bcrypt support? Date: Tue, 24 Jun 2014 06:00:36 +0400 Message-ID: <20140624020035.GA6669@openwall.com> References: <20140623215357.GB564@muslin> <20140623223339.GP179@brightrain.aerifal.cx> <20140623231735.GA4835@openwall.com> <20140623235254.GQ179@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1403575249 26382 80.91.229.3 (24 Jun 2014 02:00:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Jun 2014 02:00:49 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5318-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 24 04:00:42 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WzG2L-0002mF-KG for gllmg-musl@plane.gmane.org; Tue, 24 Jun 2014 04:00:41 +0200 Original-Received: (qmail 3512 invoked by uid 550); 24 Jun 2014 02:00:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3504 invoked from network); 24 Jun 2014 02:00:40 -0000 Content-Disposition: inline In-Reply-To: <20140623235254.GQ179@brightrain.aerifal.cx> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:5313 Archived-At: On Mon, Jun 23, 2014 at 07:52:55PM -0400, Rich Felker wrote: > On Tue, Jun 24, 2014 at 03:17:35AM +0400, Solar Designer wrote: > > On Mon, Jun 23, 2014 at 06:33:39PM -0400, Rich Felker wrote: > > > The best way to do this is with runtime detection: simply attempt to > > > use crypt or crypt_r with a setting string that requests bcrypt and > > > see if it works. > > > > Sure. This works for ./configure when we're fine with static > > compile-time detection. > > Yes; I rather frown upon such compile-time detection though because it > precludes cross-compiling, and because such _behaviors_ (as opposed to > interfaces) tend to be things that change between versions. In the > case of libc supporting bcrypt this is not going to change, but in > principle it's a bad policy. Especially when presence/absence of a > feature might depend on kernel, and running on an older kernel than > the one used while compiling is likely to happen. Presence/absence of bcrypt support may vary between (patched) glibc versions and builds, especially since it's not available upstream. > > Unfortunately, at runtime detecting bcrypt in > > this way is a bit slow since the minimum cost setting is 4 (meaning 16 > > iterations of the eksBlowfish loop). For mkpasswd it is acceptable - > > so do it - but e.g. in phpass I am reluctant to do it that way. > > I'm not clear why it would be necessary to probe for it when not > actually attempting to use it, except in cases like providing a list > of supported hashes (e.g. --help or similar). The normal usage case > for "runtime probe" seems to be "try to use it, and report failure if > it's not available". Yes, or fallback to something else. Alexander