Passwords is incompatible with PHP 7.4 due to PHP BC break
Closed this issue · 7 comments
Password hashing algorithm identifiers are now nullable strings rather than integers.
- PASSWORD_DEFAULT was int 1; now is null
- PASSWORD_BCRYPT was int 1; now is string '2y'
- PASSWORD_ARGON2I was int 2; now is string 'argon2i'
- PASSWORD_ARGON2ID was int 3; now is string 'argon2id'
https://github.com/php/php-src/blob/39a0854307cd63685b2fe158207727a2b8c06cd7/UPGRADING#L120-L130
I would wait if it does not change.
It has passed through RFC process (https://wiki.php.net/rfc/password_registry) and the BC break was explicitly mentioned so I think that change is unlikely.
(Edit: but I don't need this right now, so feel free to wait)
I think that this type of BC break was not mentioned.
It's explicitly mentioned in the Backward Incompatible Changes section of the RFC:
Algorithm identifiers are now (nullable) strings rather than numbers.
It's further discussed in Minimizing impact to BC section of the RFC.
In order to minimize the impact of the above BC. we could overload the password_hash() and password_needs_rehash() methods to accept integer values 0, 1, 2, and 3 to function as aliases for DEFAULT, BCRYPT, ARGIN2I, and ARGON2ID, respectively. Using an int would therefore work, but would produce a deprecation warning.
But this is not related to this issue, or is it?
I don't understand the question, so instead I sent PR which shows the issue,
I'm trying to say that in Backward Incompatible Changes section they didn't mention the case when a BC break arises because of the typehint is used in the userland code.
Applications correctly using the constants such as PASSWORD_DEFAULT, PASSWORD_BCRYPT, etc… will continue to function correctly.
Nette\Security\Passwords correctly uses these constants but will not continue to work correctly.
ie. that the section is not exhaustive (Unlike for example are Nikita's RFC.)
So it is possible that over time it will appear that it breaks more code, and they change it (which is unlikely…).