Re: Recommended way to probe for bcrypt support?

[Solar Designer <solar@openwall.com>]

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