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
