On Thu, Jun 22, 2023, at 12:14, Máté Kocsis wrote: > Hi Everyone, > > As previously announced on the list, we have just started the vote about > the annual PHP deprecation RFC. > > Link to the RFC: https://wiki.php.net/rfc/deprecations_php_8_3 > Link to the discussion thread: https://externals.io/message/120422 > > The vote is open until 2023-07-06 12:00:00 UTC.
I've voted No on the mt_rand() deprecation proposal. This is a high impact deprecation without sufficient justification. I believe this proposal would have been much better served deprecating only the srand() and mt_srand() functions, as I previously suggested. Going through the arguments against mt_rand() in the RFC: > They are not cryptographically secure. This is a feature, not a bug. Not everything needs or wants cryptographically secure random numbers. There's a reason we support both. > They are not properly reproducible, because the state could be changed > unpredictably by any function call, e.g. when a library is updated and adds > additional calls to `mt_rand <http://www.php.net/mt_rand>()`. This is addressed by deprecating mt_srand() only, making Randomizer the only way to get reproducible random number sequences, and relegating mt_rand() to only the cases where reproducibility is not required. > Any function calling `mt_srand <http://www.php.net/mt_srand>()` with a fixed > seed for whatever reason, will ruin randomness for the remainder of the > request. Deprecating (and removing) mt_srand() address this one trivially. > PHP's Mt19937 implementation only supports passing a single 32 bit integer as > the initial seed. Thus there are only ~4 billion possible sequences of random > integers generated by Mt19937. If a random seed is used, collisions are > expected with 50% probability after roughly 2**16 seeds (as per the birthday > paradox). In other words: After roughly 80000 requests without explicit > seeding it is likely that a seed and thus a sequence is reused. Deprecating (and removing) allows us to address this as well, as we are no longer bound to a specific PRNG algorithm or seeding procedure. > Both the quality of the returned randomness as well as the generation > performance of Mt19937 is worse than that of the Xoshiro256StarStar and > PcgOneseq128XslRr64 engines that are provided in the object-oriented API. Same as previous point: If we don't allow seeding we can change the algorithm however we like. > They are functions with overloaded signatures > <https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures>, > which are problematic for the reasons outlined in the “Deprecate functions > with overloaded signatures > <https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures>” > RFC. While this is technically true, the particular overload in question here is a very mild and unproblematic one. It only enforces that the function is called with zero or two arguments, forbidding one argument. It does not require accepting different combinations of argument types, or change the meaning of arguments, which is what makes overloads problematic. I think the only somewhat sound motivation for this deprecation is that programmers may use the non-cryptographic mt_rand() in a context where cryptographic numbers are required. This is a legitimate concern, but I don't think it's sufficient to deprecate such a widely used function. For the longest time, we only had mt_rand(), and no easy access to a CRPRNG. A lot of mt_rand() misuse dates back to that time. Since the introduction of random_int() and random_string(), getting cryptographic randomness is no harder than getting non-cryptographic randomness (easier, in the case of strings). Regards, Nikita
