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.coll...@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 > >
