[RFC] [Vote] PHP 8.3 deprecations

Den 2023-06-22 kl. 14:52, skrev Nicolas Grekas:

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.

Thanks Mate for moving all this forward.

I wish we could have voted to keep rand() and getrandmax() and just change
them to use the CSPRNG, like we do for array_rand() & co. but I guess this
should have been proposed earlier. Might be worth a small follow up RFC to
not disrupt the current one.

Cheers,
Nicolas

Sounds like a good idea to me, keeping the functions and making them
better. Hope it will fly!

Not sure if this is a relevant comparison, but we have code that we now
need to change due to deprecation of utf8_decode and utf8_encode. It is
code that has been working flawlessly for 9 years, so it's only work and
no benefit. Given that deprecations are piling up for 8.x track I think
one should be a bit cautious when approaching the next major version.

r//Björn L

2023年6月24日(土) 22:56 Nikita Popov nikita.ppv@gmail.com:

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