Thanks.
Deprecation will be done only to prevent unintended MT state dependent
code. We don't plan to go as far as removing the implementation for now.
> Firstly, making these functions independent of mt_srand() is a breaking
change, so cannot happen until PHP 9.0 at the earliest.
To be honest, I don't understand how far PHP is willing to go to accept
disruptive changes.
For example, mt_rand(), when called in its uninitialized state, was
initialized using Combined LCG (time + PID/TID) before PHP 8.0.
This can bias the results of mt_rand(), so I sent a PR on GitHub and it
was changed to use php_random_bytes() if possible.
https://github.com/php/php-src/pull/6520
It was in PHP 7.1 that the shuffle(), str_shuffle(), and
array_rand()
functions were changed to use MT-based random numbers instead of
libc-derived random numbers. This was clearly disruptive, and left no way
to even maintain backward compatibility.
Compared to that, this proposal is not disruptive in the sense that it
provides a complete alternative.
2021年5月19日(水) 2:43 Rowan Tommins <rowan.collins@gmail.com>:
> On 18/05/2021 17:19, Go Kudo wrote:
> > I have created a draft of the RFC.
> >
> > https://wiki.php.net/rfc/rng_extension
>
>
> Hi,
>
> At a glance, I think this looks like a good clear approach.
>
> I think deprecating mt_srand makes sense, but could do with a heading to
> make sure it's not overlooked, and include a clear statement of when it
> would be removed (9.0? 10.0?). It could potentially even be a separate
> vote, as keeping it doesn't actually harm users of the new classes.
>
>
> I have a few concerns with the third part of the proposal:
>
> > Also, change the following function to use the same method as
> random_byte() (the php_random_bytes() internal function) for processing,
> instead of PHP's global state.
>
> Firstly, making these functions independent of mt_srand() is a breaking
> change, so cannot happen until PHP 9.0 at the earliest. This could
> happen at the same time as mt_srand() is removed, but that connection
> needs to be clear in the proposal.
>
> Secondly, it seems inconsistent to make these functions use the
> crypto-strong randomness source, but retain rand() and mt_rand() using
> PRNGs. In fact, I don't see the need to change them at all - they can be
> documented as not for cryptographic use, as mt_rand is, and users
> pointed to the new API if they need something stronger.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>