On 8/5/16, 12:36 PM, "Charles R. Portwood II"
<[email protected] on behalf of [email protected]>
wrote:
>I understand what you're saying. Ryan said it a bit more clearly than I
>did, making the options required causes backwards-incompatible changes to
>the password_hash API. That's my real reservation behind not providing
>defaults.
>
>A separate RFC would be needed for 7.4 to make PASSWORD_ARGON2I =
>PASSWORD_DEFAULT). If the supplied constants need to be changed for that,
>I think that would be the time to do so. I think for now something needs
>to be provided to ensure the password_hash API doesn't change.
I can understand an argument that it's too much to expect a user to
provide an options array when using Argon2. But I don't understand how my
suggestion breaks BC. In my idea, a future RFC would propose default cost
constants. Changing PASSWORD_DEFAULT to PASSWORD_ARGON2I depends on those
constants so they would need to be defined before changing
PASSWORD_DEFAULT or at the same time. So...
password_hash('password', PASSWORD_DEFAULT) will always work.
password_hash('password', PASSWORD_ARGON2I) works as soon as Argon2 is
introduced in your proposal, but has to wait for another future RFC in my
suggested change.
password_hash('password', PASSWORD_ARGON2I, [costs]) will always work.
How does a BC break happen?
Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
