@mbabker

The argon2i problem is because your PHP 7.2 doesn't support this hashing method.
But it doesn't make any sense that the workflow table doesn't exist.

Could you retry with the today nightly and PHP 7.1?

For the issue with the workflow table see #21582 for the explanation - it is an issue with the mysql NOT the php version

He reported 2 things, one for his php version and one for the missing table.

And I commented on just one :)

This really should be separate bug reports because it's hard to differentiate where one thing stops and another starts here.

Core doesn't even opportunistically try to enable use of Argon2i password hashes. Really the only way it would be possible to get that error is if something put a Argon2i hash into your user's password field in the database (again, it wouldn't be core, we have an encoder supporting it but everything uses Bcrypt still; you would need a plugin to change the core handling to Argon2i or have a rogue sysadmin somewhere changing hashes), core will try to validate a hash if it detects the $argon2i prefix on the given hash but that's really the only active code path for Argon2i right now.

It was 1 installation with several problems before I saw the backend. And all problems are ordered chronologically in my first post.

0.) Updates fail because some PRs were bombed into Joomla without testing.

1.) New installation: Used Nightly Build FULL doesn't create an user during installation. Prio 1.

2.) If you create an user then via database like recommended...

See Headline "SQL code for use with Joomla"

and/or with MD5, SHA1, whatever in phpMyAdmin.

PHP 7.2 throws argoni error because this password is not accepted. I think but don't know because it's somehow identified as an argoni password BY JOOMLA.

PHP 7.1 accepts the password.

3.) Installed Joomla is useless and tester has wasted 2 h without testing and goes to bed and is not willing to test J4 for the next months again.
Because Nightly Builds where the last fallback to get an installable J4

(and because he tested all these clever and "simple" composer, nodejs, npm, build instructions (THAT don't work) with several linux distributions, several extension versions during several nights before. With WSL and without (= "real linux"). And I'm not a beginner concerning linux and server configurations and Joomla.)

So, I could change the issue title to "What do you expect from testers?" Sorry, please, that I'm really pissed meanwhile.

2.) If you create an user then via database like recommended...

could you please post the password string from the database here?

1.) New installation: Used Nightly Build FULL doesn't create an user during installation. Prio 1.

if you are kind enough please test to nights nightly, important WF changes got merged.

Installed Joomla is useless and tester has wasted 2 h without testing

Sorry about this but don't be to frustrated it took me 2 hours to install phpcs today and some more to get npm running yesterday on one of my servers, so you are not alone, even if this doesn't help much

PHP 7.2 throws argoni error because this password is not accepted. I think but don't know because it's somehow identified as an argoni password BY JOOMLA.

Argon2i support shouldn't even be getting turned on unless an environment very explicitly supports it. If you're even getting an error message related to that it means this check is passing on your environment which means this method is getting triggered in the password verification process and failing out for lack of support (which is problematic because that means the support check is giving a false positive). So something about your PHP 7.2 environment is doing enough to tell Joomla that Argon2i is potentially available for use. This all is very specific to your system's environment and without knowing details on the PHP builds it's honestly hard to say why things are going the way they're going for you.

I think but don't know because it's somehow identified as an argoni password BY JOOMLA.

That can't happen. We have very explicit checks for known password prefixes and if a given hash doesn't match any of those, then we fall back to a "chained" handler which basically tries every supported hash mechanism on the environment (see here for how that chain is constructed, again it makes very explicit environment support checks for the Argon2 stuff and your PHP 7.2 environment is reporting that support is available, that is why it's getting added to the chain, we still don't have a reason why the verification method hits the unsupported exception though).

could you please post the password string from the database here?

I've linked the sql query where you can see one. I've tested others wit same results.

OffTopic:

so you are not alone

I know and that's the reason why I've written

"What do you expect from testers?"

I'm one of the idiots that asked several "normal" users to help testing with Nightly Builds; with a comment "but be aware that small issues can occur because it's alpha". And in some days there are several "Pizza, bugs and Fun" events for testing Joomla 4. What shall they install on their local machine (crystal ball)?

if you are kind enough please test to nights nightly

How many time do you think have people like me? Change the merge concept of Joomla 4! I can live with many many failures but merging things like com_workflow without testing the installation steps before... Build is soooo easy, I've heard and read...

E.g. Why were the libraries directories removed so early? From my point of view this should have been done later on when Joomla4 is one step before beta and after all these build steps were tested on several current (!!!!!!) linux distros. Did you read the funny doc concerning this matter?

In the past I would have clicked "Clone or download" whenever I have time and would have a installable Joomla with all currently merged changes. Now I have to wait 24h before I can start testing again.

E.g. why were testing sample datas removed so early. The concerning plugin is broken.

All I mean to say: Don't wonder if testers run away and new testers are completely overstrained and frustrated. At the moment I'm telling them not to test Joomla 4 if they send me mails.

end OffTopic

without knowing details on the PHP builds it's honestly hard to say why things are going the way they're going for you

It's a standard account at provider All-Inkl. It was not my first installation and/or update of Joomla 4 with PHP 7.2.7 there.

I will test again later.

Concerning Argon2i error

The password hash is d2064d358136996bd22421584a7cb33e:trd7TvKHx6dMeoMmBVxYmg0vuXEA4199

The exception is thrown in

libraries/vendor/joomla/authentication/src/Password/Argon2iHandler.php

	public function validatePassword($plaintext, $hashed)
	{
		// Use the password extension if able
		if (version_compare(PHP_VERSION, '7.2', '>=') && \defined('PASSWORD_ARGON2I'))
		{
			return password_verify($plaintext, $hashed);
		}

		// Use the sodium extension (PHP 7.2 native or PECL 2.x) if able
		if (function_exists('sodium_crypto_pwhash_str_verify'))
		{
			$valid = sodium_crypto_pwhash_str_verify($hashed, $plaintext);
			sodium_memzero($plaintext);

			return $valid;
		}

		// Use the libsodium extension (PECL 1.x) if able
		if (extension_loaded('libsodium'))
		{
			$valid = \Sodium\crypto_pwhash_str_verify($hashed, $plaintext);
			\Sodium\memzero($plaintext);

			return $valid;
		}

		throw new \LogicException('Argon2i algorithm is not supported.');
	}

PHP info says (EdIT: seems not tom be relevant here)

sodium support | enabled
-- | --
libsodium headers version | 1.0.8
libsodium library version | 1.0.8

libraries/src/User/UserHelper.php

The handler object used in verifyPassword()of line
$match = $handler->validatePassword($password, $hash);
contains

Joomla\CMS\Authentication\Password\ChainedHandler Object
(
    [handlers:Joomla\CMS\Authentication\Password\ChainedHandler:private] => Array
        (
            [0] => Joomla\CMS\Authentication\Password\BCryptHandler Object
                (
                )

            [1] => Joomla\CMS\Authentication\Password\Argon2iHandler Object
                (
                )

            [2] => Joomla\CMS\Authentication\Password\PHPassHandler Object
                (
                )

            [3] => Joomla\CMS\Authentication\Password\SHA256Handler Object
                (
                )

            [4] => Joomla\CMS\Authentication\Password\MD5Handler Object
                (
                )

        )

)

ChainedHandler::validatePassword() goes through all of these provided handlers.

While the first handler (BCryptHandler) returns a boolean false (OK), the second (Argon2iHandler) throws a killing exception.

Thus, the needed MD5Handler for this password hash is never received in this handler chain.

That bit is honestly starting to sound like an environment issue, or you've got one of the weirdest PHP setups I've seen.

Taking the support check step by step...

Is defined('PASSWORD_ARGON2I') passing or no? This would stipulate whether PHP is able to use the native password_* functions and not even attempt to use the (lib)sodium library.

How about the result of \ParagonIE_Sodium_Compat::crypto_pwhash_is_available()? IIRC the sodium library doesn't fully polyfill all of the needed capabilities for the password hashing stuff to work so that method exists to make sure that the polyfill's presence doesn't cause environments to falsely report Argon2i password hashing support simply because the polyfill actually does declare certain functions.

sodium support | enabled should mean the function_exists('sodium_crypto_pwhash_str_verify') check in the verify method should pass. If that fails yet function_exists('sodium_crypto_pwhash_str') passes (assuming that's what in the isSupported check is making it pass in your environment), that really seems like it's a local build issue.

Lastly, with libsodium headers version | 1.0.8 and libsodium library version | 1.0.8 that would seem to imply that extension_loaded('libsodium') should pass (unless that's a library dependency of the sodium extension, been a while since I had to build/update a PHP 7.2 environment and with the stuff being renamed it's possible I'm mis-remembering something).

Something here is off. The password handlers haven't really changed at all since introduction into the Framework repo and here in the CMS repo, so it's strange to me that if it was working before today and out-of-the-blue is no longer working that it has anything to do with our code, but honestly stranger things have happened.

Is defined('PASSWORD_ARGON2I') passing or no?

No. It is not defined.

Argon2iHandler::isSupported (called by https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Service/Provider/Authentication.php#L76 )

returns true with this check

https://github.com/joomla-framework/authentication/blob/master/src/Password/Argon2iHandler.php#L81-L85

or you've got one of the weirdest PHP setups I've seen.

Maybe the provider has. I'm closing here because I cannot confirm the described issues with XAMPP 7.2.7 with the same installation package.

That'll return true for one of two reasons:

• Reason 1 is you're running PHP 7.0+ with ext/sodium installed and enabled
• Reason 2 is you've got the older variant ext/libsodium installed and enabled or the Sodium\crypto_pwhash() function is callable (the return true at the very end won't apply here because the function calling that helper in this case passes in a function name so will never get past the last if condition).

So what's installed/enabled on your PHP 7.2 environment that isn't on the 7.1 environment? It sounds like some combination of either sodium or libsodium are present on the newer version (or potentially both, which might be problematic, not too sure TBH).

Sodium\crypto_pwhash() can be reported as available because of the polyfill. BUT, even if we tried to use it or *crypto_pwhash_str_verify (in whatever variant that might be available as), a SodiumException with a totally different message would be thrown versus the LogicException our handler throws when it exhausts all options.

We might be behind on the sodium_compat polyfill on J4, maybe we need to composer update that and see if we've got a reproducible bug with the polyfill library? At this point I'm comfortable saying that our code is still doing what it was originally written up to do and if there's a bug it's either in the hosting environment or the polyfill library.

libsodium supports argon2 starting with version 1.0.9 so that seams to be the reason why it fails here.

We aren't testing libsodium version though (and we really shouldn't be making an attempt to at all). We're checking that the requisite functions are available to be called and letting those parts of the API handle raising whatever errors as appropriate. If it hits the polyfill library that will throw an appropriate exception if need be. The problem with the specific environment setup that caused this issue in the first place is that it is passing the function checks to determine environment support then failing the checks when we actually try to verify the hash, and that to me sounds like an issue with the PHP build, not the version of a C library that isn't directly exposed to PHP userland space.

In PHP 7.1 library libsodium is not present.
In PHP 7.2 it is.

PHP7.1 phpinfo

PHP7.2 phpinfo

XAMPP 7.2.7 is running without libsodium.

Now I'm confused as all hell because this is starting to imply on that PHP 7.2 instance with sodium installed and enabled that function_exists('sodium_crypto_pwhash') (granted this one isn't part of the password hashing process but it is part of the same function "family", for lack of better terms), function_exists('sodium_crypto_pwhash_str'), and function_exists('sodium_crypto_pwhash_str_verify') are not all returning true. And that would be majorly problematic to say the least (sodium_crypto_pwhash_str() being the function to generate hashes using the sodium API and sodium_crypto_pwhash_str_verify() being the function to validate them).