Re: [RFC] [Vote] PHP 8.3 deprecations

On Mon, Jun 26, 2023, at 6:45 AM, Go Kudo wrote: > 2023年6月24日(土) 22:56 Nikita Popov <nikita.ppv@gmail.com>: > >> 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 > > > Hi. > > Thank you for your valuable input. I would like to ask you a few questions. > > I think you are right that deprecating srand() / > mt_srand() achieves > the goal of making it unavailable for reproducible uses. But why keep the > function name mt_rand()? > > It is certainly true that by prohibiting seeding, the PRNG algorithm can be > modified at will. But then the mt in > mt_rand() would be out of touch > with reality. If this is done merely to maintain code compatibility, then > it is not a good idea to keep naming only for compatibility. > > Also, mt_rand() has the problem of depending on the global > state of the > PHP VM. This is very dangerous in forked use cases such as Swoole, where > implicitly seeded random numbers can return the exact same result in the > post-fork process. To avoid this, the sequence must be reseeded again after > the fork is executed. If only srand() / > mt_srand() is deprecated, this > cannot be avoided. > > The only way to completely solve this problem is to have no random number > states in the global area. For this reason, I think everything should be > deprecated. If you need pure random numbers without the need for > reproducibility, we already have random_int() available. This > is the only > complete and safe way. > > Most of all, while mt_rand() is deprecated, we can wait for PHP > 9 to > actually remove it from the core. By that time, migration methods using > tools such as Rector will probably have become major. The purpose of the > deprecation is to avoid including it in new codebases that will be written > in the future. > > I look forward to your reply. > > Best Regards, > Go Kudo For me, it's about the timeline. I'm on board with getting rid of mt_rand() entirely, just not in 2 years time. The new Random extension is still very new, tutorials aren't updated for it yet, there's a few billion lines of code out there already, etc. 2 years is not enough time for deprecation. Yes, the RFC has a footnote right now that we'll have an extra vote for just that one thing come 9.0, but honestly... I have little faith in our ability to engage in that kind of advanced workflow, and it still leaves open the potential for killing off mt_rand() after only 2 years, depending on how the vote goes. If the same deprecation was planned with a longer explicit timeline (deprecate now, don't remove until 10.0, we say that now, up-front), I'd be happy to vote yes. But not with the squishiness and short timeline. --Larry Garfield