Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
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é
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
On 19-6-2023 23:27, Máté Kocsis wrote:
Hi Juliette,
For the mb_strimwidth() proposal an impact analysis is provided at the end
("over 100 projects were reviewed").
For the other proposals there isn't and we do not believe this to be
useful. We consider deprecations to be different from other RFCs that add
new features,
because functionality usually is deprecated because it is "harmful" in one
way or another. A large impact (i.e. broad usage) should not necessarily be
an
argument against deprecation. Please also keep in mind that a deprecation
is just that, a deprecation. It gives developers a heads up to migrate off
the
functionality at their own pace. We know that package maintainers are
bugged by users whenever a new deprecation message emerges in a new PHP
version,
but this doesn't mean maintainers must react right away.
Let us elaborate why we don't think impact analysis is needed here:
* As per the TYPE_CURRENCY constant is (a) completely non-functional and
(b) unfixable. As such any code that uses the constant is already broken and
the deprecation is just pointing this out, making the user aware.
* The CRYPT_* constants are possibly the least harmful part of the RFC, but
they still can be misleading to a new developer. They are trivially
polyfilled and
also trivially removed from existing code by replacing them with 1.
* MT_RAND_PHP is broken, because the sequences are not well-defined,
defeating any reason for seeding. More reasons are already given in the RFC.
* mt_rand() is everywhere and we don't believe anyone is denying that fact.
But this should not be a reason against deprecation. As the RFC outlines,
it is trivial to find this function misused with GitHub's search. We
believe that the depreciation benefit outweighs the costs for existing
users.
* ldap_connect() is already soft-deprecated in the documentation.
Regards,
The authors of th RFC
Hi Máté,
While I appreciate that _most_ of these will be low impact and are
justified, I very much disagree with that for the proposed `mt_rand()`
and friends deprecations.
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.
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.
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.
To give you some idea: work related to PHP 8.0 and 8.1 has been nine
months out of the year for each in my case for the open source projects
I'm involved with, so no, leaving that to later is not an option.
Smile,
Juliette
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
Hi Juliette,
For the mb_strimwidth() proposal an impact analysis is provided at the end
("over 100 projects were reviewed").
For the other proposals there isn't and we do not believe this to be
useful. We consider deprecations to be different from other RFCs that add
new features,
because functionality usually is deprecated because it is "harmful" in one
way or another. A large impact (i.e. broad usage) should not necessarily be
an
argument against deprecation. Please also keep in mind that a deprecation
is just that, a deprecation. It gives developers a heads up to migrate off
the
functionality at their own pace. We know that package maintainers are
bugged by users whenever a new deprecation message emerges in a new PHP
version,
but this doesn't mean maintainers must react right away.
Let us elaborate why we don't think impact analysis is needed here:
* As per the TYPE_CURRENCY constant is (a) completely non-functional and
(b) unfixable. As such any code that uses the constant is already broken and
the deprecation is just pointing this out, making the user aware.
* The CRYPT_* constants are possibly the least harmful part of the RFC, but
they still can be misleading to a new developer. They are trivially
polyfilled and
also trivially removed from existing code by replacing them with 1.
* MT_RAND_PHP is broken, because the sequences are not well-defined,
defeating any reason for seeding. More reasons are already given in the RFC.
* mt_rand() is everywhere and we don't believe anyone is denying that fact.
But this should not be a reason against deprecation. As the RFC outlines,
it is trivial to find this function misused with GitHub's search. We
believe that the depreciation benefit outweighs the costs for existing
users.
* ldap_connect() is already soft-deprecated in the documentation.
Regards,
The authors of th RFC
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
Hi Tim, On 15 June 2023 20:17:31 BST, "Tim Düsterhus" wrote: > >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. In case it's a while before I have time for a more thorough follow-up, I just want to say thank you, both for responding constructively to my concerns, and for all the work you've done and continue to do to improve this functionality and documentation. I will try to provide some feedback or suggestions on the documentation when I get a chance. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
Hi
Thank you.
On 6/15/23 20:24, Rowan Tommins wrote:
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 *s*rand 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.
--
PHP Internals - PHP Runtime Development Mailing
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
On 15/06/2023 13:14, Tim Düsterhus wrote: 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(): > 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. 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. 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. 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. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
On 15-6-2023 9:18, Máté Kocsis wrote: Hi everyone, As there was no discussion and complaint for a long time, we would like to move forward with the RFC. We believe Go and Tim answered Nikita's doubts elaborately, so we should make the question decided during the vote. Therefore, we'll start the vote on Monday, unless new problems emerge. Thanks, Máté I'm wondering why no impact analysis has been done for any of these to get an idea of how large the impact is on userland. Could this please be added to the RFC for each proposal separately ? Smile, Juliette
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
Hi On 6/15/23 13:46, Rowan Tommins wrote: While I agree with the logic of deprecating mt_rand() in general, I do think it's too early to do so in 8.3. The Random extension is very new, and To be clear: The recommended replacement for mt_rand() for the majority of use cases / applications is random_int() which is available since 7.0, not the OO API that was added in 8.2. I've personally replaced all uses of mt_rand() / rand() with random_int() at work a while ago and also sent upstream PRs to libraries we use where appropriate. still isn't fully documented in the official manual (e.g. https://www.php.net/manual/en/random.examples.php is a blank placeholder) Yes, unfortunately I could not yet get around to further completing the documentation (and will likely not in the nearer future). Not to diminish that argument, I'd like to note, that around the release of PHP 8.2 I worked on the documentation, starting with the important parts first: The newly added API and especially the Randomizer methods *are* already documented with regard to parameter and return value explanation and (real-world) examples. In fact think the documentation is in a better state than large parts of ext/intl. If anyone wants to help with the documentation, feel free to send PRs. I'm happy to review and advise! :-) let alone in third-party tutorials. I think there should be a "soft deprecation" period where we improve the guidance around which methods to use in which cases, and allow for some "organic" migration before raising notices for such a commonly used function. As part of writing the documentation for the OO API I also worked on updating the references and examples for existing functions and adding new warnings. For example mt_srand() (which is the main cause of concern) now has this large “Caution” note with regard to the seed size: https://www.php.net/manual/en/function.mt-srand.php 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. It's trivial to find (security-sensitive) code that *should* use random_int(), but uses mt_rand() using GitHub's code search. That's my main reason for the deprecation - folks don't read documentation and instead copy from old tutorials and StackOverflow. If the RFC stays as is, I will cast a No vote on that question, but I thought I'd raise the concerns early to avoid surprise. I fully expected that part to be the most contentious one in the RFC and if everyone agreed, we would not need to hold a vote. Even if the deprecation is ultimately declined, I think it's useful to at least have held the vote for two reasons: 1. It further raises awareness. 2. It gives additional information to work with. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
On Thu, 15 Jun 2023 at 08:19, Máté Kocsis wrote: > As there was no discussion and complaint for a long time, we would like to > move forward with the RFC. We believe Go and Tim answered Nikita's doubts > elaborately, so we should make the question decided during the vote. > While I agree with the logic of deprecating mt_rand() in general, I do think it's too early to do so in 8.3. The Random extension is very new, and still isn't fully documented in the official manual (e.g. https://www.php.net/manual/en/random.examples.php is a blank placeholder) let alone in third-party tutorials. I think there should be a "soft deprecation" period where we improve the guidance around which methods to use in which cases, and allow for some "organic" migration before raising notices for such a commonly used function. If the RFC stays as is, I will cast a No vote on that question, but I thought I'd raise the concerns early to avoid surprise. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
Hi everyone, As there was no discussion and complaint for a long time, we would like to move forward with the RFC. We believe Go and Tim answered Nikita's doubts elaborately, so we should make the question decided during the vote. Therefore, we'll start the vote on Monday, unless new problems emerge. Thanks, Máté
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
Hi On 5/30/23 17:52, Go Kudo wrote: > It should be deprecated with PHP 8.4 at the earliest to give folks at least Indeed, I agree that `lcg_value()` should be deprecated at least in PHP 8.4. However, `lcg_value()` remains a dangerous function. It still has a weak initial seeding problem (PID, time), not to mention global state. This is extremely dangerous for workloads on containers where PIDs tend to be fixed. Perhaps this should be documented at the time of PHP 8.3 release. As the function is not seedable in userland, we do not need to preserve a specific sequence or behavior. Therefore it should be possible to replace the seeding to make use of the CSPRNG and fall back to the old and insecure seeding if the CSPRNG fails. For the same reason, the global state is also less of a problem compared to mt_rand() and friends. Because of the above, I have removed my `lcg_value()` deprecation entry from the RFC. Thanks! Thanks! Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
2023年5月30日(火) 4:49 Tim Düsterhus : > Hi > > On 5/29/23 08:44, Go Kudo wrote: > > I realized I was about to add the deprecation of `lcg_value()` and forgot > > to do so, so I added it. > > > > https://wiki.php.net/rfc/deprecations_php_8_3#global_combined_lcg > > > > As usual, my English is of low quality, so I would appreciate it if you > > could point out any problems. > > I think it's too early for that. Because: > > 1. The replacement is only available as of PHP 8.3. Thus there won't be > a single version where "replacement is available" and "the function does > not emit deprecation notices" is both true. It should be deprecated with > PHP 8.4 at the earliest to give folks at least (!) one version to > cleanly migrate existing code without suppressing any errors / notices / > deprecations. > > 2. It's not seedable, thus the implementation can be switched to use a > different engine without affecting existing code. > > 3. It's not as commonly misused as mt_rand() is. Primarily because the > possible use-cases are much more rare. > > Best regards > Tim Düsterhus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Hi > It should be deprecated with PHP 8.4 at the earliest to give folks at least Indeed, I agree that `lcg_value()` should be deprecated at least in PHP 8.4. However, `lcg_value()` remains a dangerous function. It still has a weak initial seeding problem (PID, time), not to mention global state. This is extremely dangerous for workloads on containers where PIDs tend to be fixed. Perhaps this should be documented at the time of PHP 8.3 release. Because of the above, I have removed my `lcg_value()` deprecation entry from the RFC. Thanks! Best Regards, Go Kudo
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
Hi On 5/29/23 17:41, Nikita Popov wrote: I don't think we should deprecate mt_rand(). There are plenty of use-cases that require neither a seedable (predictable) RNG sequence, nor a cryptographically-secure RNG. For those use-cases (and especially one-off uses), mt_rand() is perfect, and going through Randomizer is an entirely unnecessary complication. I think I could get on board with deprecating srand/mt_srand to make rand/mt_rand non-seedable, directing people who need a seedable RNG to use Randomizer, which is much better suited to that use-case. However, we should retain rand/mt_rand themselves for non-seeded use-cases. I disagree. One of the arguments that I made in favor of the removal is basically that "defaults" matter: Developers should be steered to the secure-by-default choice (i.e. the CSPRNG), unless they have specific performance or reproduction requirements. I believe the current API trio of rand(), mt_rand() and random_int() fails at that, because rand() is the "most convenient" function. The function name is short and it appears in a plethora of existing tutorials. The CSPRNG should be sufficiently fast for the vast majority of use cases. My i5-2430M with Linux 5.4 can handle 1 million random_int(1, 100) calls in a second, with mt_rand(1, 100) taking 0.25 seconds for 1 million calls. The PHP 8.2 OO API very intentionally defaults the \Random\Randomizer to the Secure engine for that reason and this recommendation is also part of the documentation I wrote for ext/random: https://www.php.net/manual/en/class.random-engine-secure.php The Random\Engine\Secure engine is the recommended safe default choice, unless the application requires either reproducible sequences or very high performance. https://www.php.net/manual/en/class.random-engine.php The Random\Engine\Secure engine that is backed by a CSPRNG is the recommended safe default choice, unless the application requires either reproducible sequences or very high performance. - With srand/mt_srand removed, we also would not have to produce any particular sequence, and would be free to switch the internal RNG to something other than Mt19937. In addition to the above reasoning, rand() and mt_rand() are also functions with an overloaded signature which are problematic as per: https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures Switching them to a different engine would not do anything about the overloaded signature. I believe making a clean cut is preferable to each of the following: 1. Not changing anything. 2. Taking away seeding (and backing them by a different non-CSPRNG). 3. Making them effectively aliases to random_int(). However I also don't see a strong need for a removal in PHP 9. I am also happy with removing them with PHP 10 at the very earliest to give folks plenty of runway to migrate to something else on their preferred pace, as long as they are not introduced in any new code without proper consideration of their downsides. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
Hi On 5/29/23 08:44, Go Kudo wrote: I realized I was about to add the deprecation of `lcg_value()` and forgot to do so, so I added it. https://wiki.php.net/rfc/deprecations_php_8_3#global_combined_lcg As usual, my English is of low quality, so I would appreciate it if you could point out any problems. I think it's too early for that. Because: 1. The replacement is only available as of PHP 8.3. Thus there won't be a single version where "replacement is available" and "the function does not emit deprecation notices" is both true. It should be deprecated with PHP 8.4 at the earliest to give folks at least (!) one version to cleanly migrate existing code without suppressing any errors / notices / deprecations. 2. It's not seedable, thus the implementation can be switched to use a different engine without affecting existing code. 3. It's not as commonly misused as mt_rand() is. Primarily because the possible use-cases are much more rare. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
2023年5月30日(火) 0:42 Nikita Popov : > On Mon, May 29, 2023, at 08:05, Máté Kocsis wrote: > > Hi Everyone, > > > > Together with multiple authors, we'd like to start the discussion of the > > usual > > deprecation RFC for the subsequent PHP version. You can find the link > below: > > https://wiki.php.net/rfc/deprecations_php_8_3 > > > > Regards: > > Máté Kocsis > > I don't think we should deprecate mt_rand(). > > There are plenty of use-cases that require neither a seedable > (predictable) RNG sequence, nor a cryptographically-secure RNG. For those > use-cases (and especially one-off uses), mt_rand() is perfect, and going > through Randomizer is an entirely unnecessary complication. > > I think I could get on board with deprecating srand/mt_srand to make > rand/mt_rand non-seedable, directing people who need a seedable RNG to use > Randomizer, which is much better suited to that use-case. However, we > should retain rand/mt_rand themselves for non-seeded use-cases. > > With srand/mt_srand removed, we also would not have to produce any > particular sequence, and would be free to switch the internal RNG to > something other than Mt19937. > > The same extends to array_rand(), shuffle() and str_shuffle() -- in fact > the RFC is missing an important voting option, which is "leave them alone", > or rather "convert to some non-seedable non-CSPRNG" if you prefer. > > Regards, > Nikita +1 I too feel that the `Randomizer` is overkill for many applications. However, I believe that there is a suitable alternative to `mt_rand()` / `rand()` : `random_int()` It probably makes the most sense to use it. On the other hand, there is no suitable alternative for `lcg_value()`. The simpler `Randomizer::getFloat()` would be fine, but on the other hand, floating-point random numbers are very hard to handle, so some say that the `Randomizer` class should be used. I would like to hear your opinion on this. Best Regards, Go Kudo
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
On Mon, May 29, 2023, at 08:05, Máté Kocsis wrote: > Hi Everyone, > > Together with multiple authors, we'd like to start the discussion of the > usual > deprecation RFC for the subsequent PHP version. You can find the link below: > https://wiki.php.net/rfc/deprecations_php_8_3 > > Regards: > Máté Kocsis I don't think we should deprecate mt_rand(). There are plenty of use-cases that require neither a seedable (predictable) RNG sequence, nor a cryptographically-secure RNG. For those use-cases (and especially one-off uses), mt_rand() is perfect, and going through Randomizer is an entirely unnecessary complication. I think I could get on board with deprecating srand/mt_srand to make rand/mt_rand non-seedable, directing people who need a seedable RNG to use Randomizer, which is much better suited to that use-case. However, we should retain rand/mt_rand themselves for non-seeded use-cases. With srand/mt_srand removed, we also would not have to produce any particular sequence, and would be free to switch the internal RNG to something other than Mt19937. The same extends to array_rand(), shuffle() and str_shuffle() -- in fact the RFC is missing an important voting option, which is "leave them alone", or rather "convert to some non-seedable non-CSPRNG" if you prefer. Regards, Nikita
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
I am not sure if others agree but in my opinion, Global Mersenne Twister should have been a separate RFC. It has a discussion point that people might want to discuss on mailing list first.
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
2023年5月29日(月) 15:05 Máté Kocsis : > Hi Everyone, > > Together with multiple authors, we'd like to start the discussion of the > usual > deprecation RFC for the subsequent PHP version. You can find the link > below: > https://wiki.php.net/rfc/deprecations_php_8_3 > > Regards: > Máté Kocsis > Hi. I realized I was about to add the deprecation of `lcg_value()` and forgot to do so, so I added it. https://wiki.php.net/rfc/deprecations_php_8_3#global_combined_lcg As usual, my English is of low quality, so I would appreciate it if you could point out any problems. Best regards. Go Kudo
[PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
Hi Everyone, Together with multiple authors, we'd like to start the discussion of the usual deprecation RFC for the subsequent PHP version. You can find the link below: https://wiki.php.net/rfc/deprecations_php_8_3 Regards: Máté Kocsis
