add more bindings from libxcrypt 4.4

[remicollet]

This PR add 3 functions

• crypt_gensalt (since libxcrypt 4.0)
• crypt_checksalt (since libxcrypt 4.3)
• crypt_preferred_method (since libxcrypt 4.4)

And make new algo usable (providing the expecting salt, with algo options, may be complex)

• $y$ (yescrypt) (since libxcrypt 4.2.0)
• $gy$ (ghost-yescrypt) (since libxcrypt 4.3.0)

Examples

$hash = crypt("secret", crypt_gensalt());
$hash = crypt("secret", crypt_gensalt(crypt_preferred_method()));
$hash = crypt("secret", crypt_gensalt(CRYPT_PREFIX_BLOWFISH));

Target is libxcrypt 4.4 only, released in 2018

[cmb69]

Looks reasonable. Maybe this should also be supported on Windows.

[cmb69]

Shouldn't this be

Suggested change

	#ifdef HAVE_CRYPT_H
	#ifdef HAVE_CRYPT

[remicollet]

it is the same condition copy/paste from the one used in crypt.c

[bukka]

I'm wondering if it would be better to move crypt to the separate extension. Personally I would like to limit external lib deps on standard ext and use extension wrappers instead.

[bukka]

I think those new deps messing up the ext standard and it's no longer really standard :). The same should be done for libargon2. That might be actually maybe for later so we can just move it to PECL as there's now OpenSSL support.

[bukka]

Although libargon2 still have some more performant options so it would probably still makes sense to have it in the core. It seems a bit unmaintained though so maybe we could wrap it and include there also BLAKE3 which was requested in hash but that's a bit different thing though.

The point is that I would like to see those out of standard ext.

[cmb69]

The point is that I would like to see those out of standard ext.

Fair enough. Note that xpass is already available as PECL extension. It seems to me we're hitting the old problem that PECL extensions might not be well maintained (especially regarding possible BC breaks in new PHP versions), and the some users don't like to use PECL extensions for whatever reasons (see e.g. #17062).

[Girgias]

We could just move crypt() out of ext/standard into a new, always available extension. Similar to what ext/random did with lcg_value(), rand(), etc.

[remicollet]

I'm not a big fan of adding a new ext (crypt) only for a 4 functions set...

Yes libxcrypt is an external lib, but the standard lib used in linux distributions for password hashing (/etc/password)

This is also linked to password feature as libxcrypt also provides some new algo used in linux for password hashing which can be made available (sha512 and yescrypt , already added by xpass pecl ext). More it also provides blowfish algo which can be used (when available) instead of the bundled implementation, see compat_test.

[bukka]

We could just move crypt() out of ext/standard into a new, always available extension. Similar to what ext/random did with lcg_value(), rand(), etc.

Yeah I would prefer exactly that.

[bukka]

This is also linked to password feature as libxcrypt also provides some new algo used in linux for password hashing which can be made available (sha512 and yescrypt , already added by xpass pecl ext). More it also provides blowfish algo which can be used (when available) instead of the bundled implementation, see compat_test.

Yeah that's the whole point of having password API plugable so it can be extended from extension. Ideally it could be moved with blowfish so we remove even more stuff from ext/standard.

[cmb69]

Maybe this topic should better be discussed on the internals mailing list.

[TimWolla]

Is this a duplicate of #15870?

[remicollet]

Is this a duplicate of #15870?

Yes, I don't even remember having already done the work :s

[remicollet]

BTW as we seem to enter the bikeshedding phase, I will probably forgive and keep only xpass ext maintained.

[remicollet]

Closing per Lack of energy

[bukka]

I think xpass extension is actually better place for this considering that this is available only with xcrypt.

[bukka]

But having all the crypt stuff outside the ext/standard would be still good think to do eventually. Then those functions would fit there better. I will see if find time for this.