Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120670
Feedback-ID: id4a9467a:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-499-gf27bbf33e2-fm-20230619.001-gf27bbf33
Mime-Version: 1.0
Message-ID: <6e42df4a-1331-4a88-bf67-2e4079a8b527@app.fastmail.com>
In-Reply-To: 
 <CAH5C8xU7j-Qn9Vcry19Ug675CTj0sSjpMs-GPNYNHJJ7KsPwXg@mail.gmail.com>
References: 
 <CAH5C8xU7j-Qn9Vcry19Ug675CTj0sSjpMs-GPNYNHJJ7KsPwXg@mail.gmail.com>
Date: Sat, 24 Jun 2023 15:55:45 +0200
To: =?UTF-8?Q?M=C3=A1t=C3=A9_Kocsis?= <kocsismate90@gmail.com>,
 "Levi Morrison" <internals@lists.php.net>
Content-Type: multipart/alternative;
 boundary=7d66d8cc2fdf433897eaf07be8ba7491
Subject: Re: [PHP-DEV] [RFC] [Vote] PHP 8.3 deprecations
From: nikita.ppv@gmail.com ("Nikita Popov")

--7d66d8cc2fdf433897eaf07be8ba7491
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 22, 2023, at 12:14, M=C3=A1t=C3=A9 Kocsis wrote:
> Hi Everyone,
>=20
> As previously announced on the list, we have just started the vote abo=
ut
> the annual PHP deprecation RFC.
>=20
> Link to the RFC: https://wiki.php.net/rfc/deprecations_php_8_3
> Link to the discussion thread: https://externals.io/message/120422
>=20
> 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 impa=
ct deprecation without sufficient justification.

I believe this proposal would have been much better served deprecating o=
nly the srand() and mt_srand() functions, as I previously suggested. Goi=
ng 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 cryptographi=
cally 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 int=
eger as the initial seed. Thus there are only ~4 billion possible sequen=
ces of random integers generated by Mt19937. If a random seed is used, c=
ollisions are expected with 50% probability after roughly 2**16 seeds (a=
s per the birthday paradox). In other words: After roughly 80000 request=
s 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 algo=
rithm however we like.

> They are functions with overloaded signatures <https://wiki.php.net/rf=
c/deprecate_functions_with_overloaded_signatures>, which are problematic=
 for the reasons outlined in the =E2=80=9CDeprecate functions with overl=
oaded signatures <https://wiki.php.net/rfc/deprecate_functions_with_over=
loaded_signatures>=E2=80=9D RFC.

While this is technically true, the particular overload in question here=
 is a very mild and unproblematic one. It only enforces that the functio=
n is called with zero or two arguments, forbidding one argument. It does=
 not require accepting different combinations of argument types, or chan=
ge 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 c=
ryptographic numbers are required. This is a legitimate concern, but I d=
on'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 CRP=
RNG. A lot of mt_rand() misuse dates back to that time. Since the introd=
uction of random_int() and random_string(), getting cryptographic random=
ness is no harder than getting non-cryptographic randomness (easier, in =
the case of strings).

Regards,
Nikita
--7d66d8cc2fdf433897eaf07be8ba7491--