Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120681
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-499-gf27bbf33e2-fm-20230619.001-gf27bbf33
Mime-Version: 1.0
Message-ID: <3bb237a3-1dec-4cd1-9490-38a608ffafbc@app.fastmail.com>
In-Reply-To: 
 <CAMs36He8DPb=VJKnwFOE9Yq68Uuf0_BDtB16xQ9G+ZwsgqQScw@mail.gmail.com>
References: 
 <CAH5C8xU7j-Qn9Vcry19Ug675CTj0sSjpMs-GPNYNHJJ7KsPwXg@mail.gmail.com>
 <6e42df4a-1331-4a88-bf67-2e4079a8b527@app.fastmail.com>
 <CAMs36He8DPb=VJKnwFOE9Yq68Uuf0_BDtB16xQ9G+ZwsgqQScw@mail.gmail.com>
Date: Mon, 26 Jun 2023 15:30:11 +0000
To: "Go Kudo" <g-kudo@colopl.co.jp>,
 "php internals" <internals@lists.php.net>,
 "nikita.ppv@gmail.com" <nikita.ppv@gmail.com>,
 =?UTF-8?Q?Tim_D=C3=BCsterhus?= <timwolla@bastelstu.be>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Vote] PHP 8.3 deprecations
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Jun 26, 2023, at 6:45 AM, Go Kudo wrote:
> 2023=E5=B9=B46=E6=9C=8824=E6=97=A5(=E5=9C=9F) 22:56 Nikita Popov <niki=
ta.ppv@gmail.com>:
>
>> On Thu, Jun 22, 2023, at 12:14, M=C3=A1t=C3=A9 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 i=
mpact
>> 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 chan=
ged
>> unpredictably by any function call, e.g. when a library is updated an=
d adds
>> additional calls to `mt_rand <http://www.php.net/mt_rand>()`.
>>
>> This is addressed by deprecating mt_srand() only, making Randomizer t=
he
>> 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>()` wit=
h a
>> fixed seed for whatever reason, will ruin randomness for the remainde=
r 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 80=
000
>> 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 a=
re no
>> longer bound to a specific PRNG algorithm or seeding procedure.
>>
>> > Both the quality of the returned randomness as well as the generati=
on
>> performance of Mt19937 is worse than that of the Xoshiro256StarStar a=
nd
>> 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_signatur=
es>,
>> which are problematic for the reasons outlined in the =E2=80=9CDeprec=
ate functions
>> with overloaded signatures <
>> https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatur=
es>=E2=80=9D
>> RFC.
>>
>> While this is technically true, the particular overload in question h=
ere
>> is a very mild and unproblematic one. It only enforces that the funct=
ion is
>> called with zero or two arguments, forbidding one argument. It does n=
ot
>> 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 th=
at
>> 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 cryptograph=
ic
>> randomness is no harder than getting non-cryptographic randomness (ea=
sier,
>> in the case of strings).
>>
>> Regards,
>> Nikita
>
>
> Hi.
>
> Thank you for your valuable input. I would like to ask you a few quest=
ions.
>
> I think you are right that deprecating `srand()` / `mt_srand()` achiev=
es
> 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 c=
an be
> modified at will. But then the `mt` in `mt_rand()` would be out of tou=
ch
> with reality. If this is done merely to maintain code compatibility, t=
hen
> 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, whe=
re
> implicitly seeded random numbers can return the exact same result in t=
he
> 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 num=
ber
> 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 t=
he
> deprecation is to avoid including it in new codebases that will be wri=
tten
> 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_ra=
nd() entirely, just not in 2 years time.  The new Random extension is st=
ill 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 d=
eprecation.

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 leave=
s open the potential for killing off mt_rand() after only 2 years, depen=
ding on how the vote goes.

If the same deprecation was planned with a longer explicit timeline (dep=
recate 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