[RFC] [Discussion] PHP 8.3 deprecations

Hi

Thank you.

Looping back to the beginning of my email: The recommended replacement
is random_int() which is available for years, but the "organic"
migration did not really work.

I think that's partly because, rightly or wrongly, random_int() is not
generally viewed as a universal replacement for rand()/mt_rand(). For
instance, consider the opening description in the manual for random_int():

For the explanation of the new OO API I took great care to document
Random\Engine\Secure (which uses the same underlying randomness as
random_int and random_bytes) as the default choice. See the
documentation quotes in my reply to Nikita.

Due to needing to prioritize I did not yet get around to bringing up the
existing documentation fully up to shape, except for necessary cleanup work.

Writing a good high-level description is especially hard (that's also
what the Randomizer methods are still lacking). My goal here was not to
have some "okay-ish" documentation that needs multiple revisions due to
being wrong, but great documentation.

Generates cryptographic random integers that are suitable for use
where unbiased results are critical, such as when shuffling a deck of
cards for a poker game.

Agreed, this is not ideal to sell random_int() as the default choice for
all things being equal. I've made an attempt for a more neutral /
inclusive wording in https://github.com/php/doc-en/pull/2528. Parts of
the description have been copied as-is from the explanation of the
Secure engine.

And the Caution on the manual for rand() and mt_rand():

This function does not generate cryptographically secure values, and
/must not/ be used for cryptographic purposes, or purposes that require
returned values to be unguessable.

Note that both talk about using random_int() in particular situations,
not as a universal replacement.

This case is a little more complicated, because there are multiple
issues and the existing description of mt_rand() is not particularly
good in the first place [1]:

• They are not cryptosafe. This is mentioned.
• The randomness is not particularly good even outside of cryptographic
  applications. The main reason for this is the abysmal seeding, which
  is mentioned in the srand docs. Perhaps the Caution note in
  mt_srand() should also be applied to mt_rand() itself? At that point the
  documentation turns into a giant warning though, which technically isn't
  wrong, but should probably be considered to be an indicator that
  mt_rand() is broken beyond repair.

[1] It starts by describing something about "libc randomness", using
terms the average developer knows nothing about.

Add to that the scary fact that random_int() can fail with an exception
(the technical detail of how unlikely that is probably goes over the
head of the majority of PHP programmers), and the perception that it's
significantly slower (which may or may not be true, or relevant to most
users), and many people will be actively choosing not to use it when
they don't need its guarantees.

Yeah, I get behind that. Let me just answer this here for the record:

1. The CSPRNG can technically fail, it is effectively infallible on
   modern operating systems, unless the system is severely misconfigured.

2. The CSPRNG is slower than a non-CS PRNG, but this is not likely to
   matter for the majority of applications. If it matters then Mt19937
   (which is what is behind mt_rand()) is not the right choice anyway.
   xoshiro256** is - that's the fastest engine PHP provides.

On the other hand, I'm sure you're right that there are people misusing
rand()/mt_rand() in contexts where they really should use something
secure. Maybe with improved documentation at the same time, a
deprecation could be OK; but it would be worryingly easy to say
"deprecate first, we'll get round to the documentation later", and have
lots of confused users who think we're suddenly deprecating something
that's been working fine for 20 years.

Please see my PR above. I'm putting my money where my mouth is to
improve the documentation and I'm looking forward to your ("you"
referring to the broader audience of this email) feedback with regard to
improving the documentation here. If you think you have something
worthwhile to add, please add a review or send your own PR and ping me
(@TimWolla) on it. My list of PRs might be a good starting point with
regard to the changes and improvements I've made (or attempted to make)
in the past:

https://github.com/php/doc-en/pulls?q=is%3Apr+author%3ATimWolla+is%3Aclosed

Best regards
Tim Düsterhus

PS: Don't get me started on uniqid() which I consider to be the most
misused function in PHP with horrible constructs like
sha1(md5(uniqid(mt_rand() . microtime(), true) . mt_rand())). I hope to
deprecate that one with 8.4, because getBytesFromString() is available
then as a reasonable replacement.

Hi Juliette,

There are plenty of situations where it is of absolutely no interest to

get a crypographically secure value, like for generating some
semi-random test data and I strongly believe the impact of these
deprecations to be large and fixing it won't always be trivial for
codebases which support a range of PHP versions.

Please note that Tim has just added a clarification regarding the removal of
mt_rand():

For the Global Mersenne Twister specifically the removal will be left to an

additional later vote,

allowing to defer the removal based on the remaining usage.

This means that mt_rand() will most probably have a longer phasing out
period than normally, but at least
this buys us time to evaluate the timeframe of the removal. I hope that we
addressed your concerns.

As a matter of principle I believe there should be an impact analysis

for anything being deprecated. It can inform the voters as to the
appropriateness of the timing of the deprecation - early on in a major
cycle vs late in a major cycle -. Others may just take it as a FYI, but
at least they have access to the information if they wanted to assess it.

I don't think an impact analysis is useful all the time: sometimes because
it doesn't make much sense
trying to measure the impact of deprecating very rare or broken
functionality (e.g.
CRYPT_STD_* or the NumberFormatter::TYPE_CURRENCY constants). In other
cases, the analysis is
likely going to be misleading, since we don't have access to proprietary
code, and some functionality
is used in such code more often than in open-source projects (e.g. the
typical example is session-related
functions).

While I appreciate what you are saying about deprecations being an
"action list to migrate at your own pace", the reality for open source
packages is different as the sheer amount of deprecations over the past
few years have taken huge amounts of time to address and "leaving those
till later" is just not an option as the amount of time needed is the
same and time can only be spend once.

Please let me clarify first that we do appreciate your dedication and
efforts a lot for maintaining such critical projects.
At the same time, - since PHP has almost 3 decades long of track record of
doing silly things -, we as maintainers
are also dedicated very much about improving our language and getting rid
of its unreliable/unexpected/unsafe behavior.

I also do believe that we do care about our users, and it's very rare that
some change is introduced without a heads up
multiple years before the removal. I know these deprecations and removals
usually feel like a burden for people who
tirelessly work on following these changes in their open-source projects in
their free time, but please do understand that
PHP would still be the same crazy language without the fundamental changes
which have been being introduced
in the recent years. We are happy to discuss the underlying problem
separately from this RFC, since the root cause
may be something else than the too many deprecations, starting from things
which we do not have control over (the underfincaning
of open source work) to other factors which we can control (e.g. the
minimum length of deprecation before
the removal, shorter/longer major version cycles, educating end-users to
use automation like Rector).

With all that said, we're going to start the vote on Thursday, since we do
believe the proposal is clear enough now, and
there's not much to discuss anymore.

Regards,
Máté