# [RFC] RNG fixes
- Thread: https://externals.io/message/93959
- Original archive: https://news-web.php.net/php.internals/93959
- Started by Leigh on 2016-06-14T16:46:00+00:00
- Messages: 74
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/93959.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt
---
## #93959 — Leigh — 2016-06-14T16:46:00+00:00
URL: https://externals.io/message/93959#93959
Hey Internals,
I realise I'm cutting it close with this one, but I want to propose some
changes to our standard random number generators.
The downside of this proposal is that our RNGs (rand() and `mt_rand()`) are
seedable and reproduce identical streams (platform dependant) for any given
seed. However their implementations are broken or inconsistent, so we need
to weigh up the cost of changing these sequences versus having solid
implementations.
It is my opinion that if we are going to make any changes to these
functions, we should make all of the changes at the same time and avoid any
future disruption to their output.
The RFC contains a few proposals, some of them depend on each other while
others are standalone. Throughout the discussion phase I hope to reduce the
number of proposals down to a consensus we can vote on in two weeks time.
I will release a patch when I have a better feeling for the direction we
want to take.
The issues I want to bring up for discussion are.
* Replacing `mt_rand()` and `rand()` to a strong, modern RNG.
* Alternatively, fixing the current `mt_rand()` implementation to make it
standard
* Aliasing `rand()` to `mt_rand()` to improve output and cross-platform support
* Fixing RAND_RANGE for large ranges.
* Replacing insecure uses of php_rand() with php_random_bytes()
* Making the `array_rand()` algorithm more efficient
The RFC can be found here: https://wiki.php.net/rfc/rng_fixes
If anyone knows of other fixes that should be made at the same time but I
have overlooked, please let me know so I can get them included.
Regards,
Leigh.
---
## #93961 — Scott Arciszewski — 2016-06-14T16:49:10+00:00
URL: https://externals.io/message/93959#93961 · In reply to: #93959
> Hey Internals,
>
> I realise I'm cutting it close with this one, but I want to propose some
> changes to our standard random number generators.
>
> The downside of this proposal is that our RNGs (rand() and `mt_rand()`) are
> seedable and reproduce identical streams (platform dependant) for any given
> seed. However their implementations are broken or inconsistent, so we need
> to weigh up the cost of changing these sequences versus having solid
> implementations.
>
> It is my opinion that if we are going to make any changes to these
> functions, we should make all of the changes at the same time and avoid any
> future disruption to their output.
>
> The RFC contains a few proposals, some of them depend on each other while
> others are standalone. Throughout the discussion phase I hope to reduce the
> number of proposals down to a consensus we can vote on in two weeks time.
>
> I will release a patch when I have a better feeling for the direction we
> want to take.
>
> The issues I want to bring up for discussion are.
>
> * Replacing `mt_rand()` and `rand()` to a strong, modern RNG.
> * Alternatively, fixing the current `mt_rand()` implementation to make it
> standard
> * Aliasing `rand()` to `mt_rand()` to improve output and cross-platform support
> * Fixing RAND_RANGE for large ranges.
> * Replacing insecure uses of php_rand() with php_random_bytes()
> * Making the `array_rand()` algorithm more efficient
>
> The RFC can be found here: https://wiki.php.net/rfc/rng_fixes
>
> If anyone knows of other fixes that should be made at the same time but I
> have overlooked, please let me know so I can get them included.
>
> Regards,
>
> Leigh.
>
Good idea. I'm particularly fond of PCG over MT and LCG (but would not
ever use it for a CSPRNG).
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises
---
## #93962 — Fleshgrinder — 2016-06-14T17:45:29+00:00
URL: https://externals.io/message/93959#93962 · In reply to: #93959
> The issues I want to bring up for discussion are.
>
> * Replacing `mt_rand()` and `rand()` to a strong, modern RNG.
> * Alternatively, fixing the current `mt_rand()` implementation to make it
> standard
> * Aliasing `rand()` to `mt_rand()` to improve output and cross-platform support
> * Fixing RAND_RANGE for large ranges.
> * Replacing insecure uses of php_rand() with php_random_bytes()
> * Making the `array_rand()` algorithm more efficient
>
> The RFC can be found here: https://wiki.php.net/rfc/rng_fixes
>
Why do we need so many functions to get a random int anyways if we now
have `random_int()`? I would like to see all of them deprecated and
removed in PHP 8.0.
- `crypt()` -> `password_hash()`
- `rand()` -> `random_int()`
- `mt_getrandmax()` -> `PHP_INT_MAX`
- `mt_rand()` -> `random_int()`
- `mt_srand()` -> -
- `shuffle()` -> array_shuffle()*
- `srand()` -> -
Mcrypt is meant to be replaced anyways and OpenSSL might be too if we
can come up with a nicer implementation that actually hides the
underlying library (e.g. sodium).
* Directly fix the name and get rid of the reference:
array_shuffle(array $array, int $num = 1): array
I do not see a problem to change `array_rand()`, array_shuffle(), nor
`str_shuffle()` since their output should be random anyways.
--
Richard "Fleshgrinder" Fussenegger
---
## #93965 — Christoph Becker — 2016-06-14T18:14:31+00:00
URL: https://externals.io/message/93959#93965 · In reply to: #93962
>
> > […]
>
> Why do we need so many functions to get a random int anyways if we now
> have `random_int()`? I would like to see all of them deprecated and
> removed in PHP 8.0.
In my opinion, we need at least one random function which yields
reproducible values.
--
Christoph M. Becker
---
## #93967 — Leigh — 2016-06-14T18:44:28+00:00
URL: https://externals.io/message/93959#93967 · In reply to: #93962
> Why do we need so many functions to get a random int anyways if we now
> have `random_int()`? I would like to see all of them deprecated and
> removed in PHP 8.0.
Lets see if others support this option. (I'm not even sure I do right now)
> I do not see a problem to change `array_rand()`, array_shuffle(), nor
> `str_shuffle()` since their output should be random anyways.
>
Right now a call to `srand()` with a given seed will make these functions
return the same sequence of outputs for a particular set of inputs. This
behaviour is fine and sometimes even desirable. The changes in this RFC
will change those outputs, they will still be controllable with `srand()`
though
---
## #93968 — Leigh — 2016-06-14T18:46:06+00:00
URL: https://externals.io/message/93959#93968 · In reply to: #93965
>
> In my opinion, we need at least one random function which yields
> reproducible values.
>
> --
> Christoph M. Becker
>
Hi Christoph,
Even with the proposed changes both functions will still be capable of
reproducible sequences, just different sequences than before the changes.
---
## #93970 — Christoph Becker — 2016-06-14T18:56:53+00:00
URL: https://externals.io/message/93959#93970 · In reply to: #93968
>
>
> > […]
>
> Even with the proposed changes both functions will still be capable of
> reproducible sequences, just different sequences than before the changes.
Yes, I'm aware of that, and that change isn't an issue for me (except
maybe that it might happen in a minor version). I was responding to
Richard (Fleshgrinder) who suggested to remove `rand()` and `mt_rand()`
alltogether, because there is `random_int()`.
--
Christoph M. Becker
---
## #93972 — Fleshgrinder — 2016-06-14T19:12:12+00:00
URL: https://externals.io/message/93959#93972 · In reply to: #93970
> Yes, I'm aware of that, and that change isn't an issue for me (except
> maybe that it might happen in a minor version). I was responding to
> Richard (Fleshgrinder) who suggested to remove `rand()` and `mt_rand()`
> alltogether, because there is `random_int()`.
>
I understood how you mean it. :)
Call me ignorant but is this required in typical web applications?
Couldn't we move this functionality to PECL? I mean, it is required in
games but other than that.
Please correct me if that is wrong!
--
Richard "Fleshgrinder" Fussenegger
---
## #93975 — Davey Shafik — 2016-06-14T19:56:21+00:00
URL: https://externals.io/message/93959#93975 · In reply to: #93972
>
> > […]
>
> I understood how you mean it. :)
>
> Call me ignorant but is this required in typical web applications?
> Couldn't we move this functionality to PECL? I mean, it is required in
> games but other than that.
>
> Please correct me if that is wrong!
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>
I think as this is a BC break it should require the 2/3 majority. I do
support fixing the RNGs though.
Have you done any checks on GitHub etc to see how widespread this usage is?
I'd like to get some data on that too.
---
## #93982 — Scott Arciszewski — 2016-06-14T21:20:03+00:00
URL: https://externals.io/message/93959#93982 · In reply to: #93975
>
>
> > […]
> I think as this is a BC break it should require the 2/3 majority. I do
> support fixing the RNGs though.
>
> Have you done any checks on GitHub etc to see how widespread this usage is?
> I'd like to get some data on that too.
>
I don't have data, but a word of caution: Don't grep legacy crypto
libraries for use of `rand()` or `mt_rand()` for key/IV generation if you want
to feel any sense of optimism. Speaking from experience here! ;)
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises
---
## #93983 — Leigh — 2016-06-14T22:19:31+00:00
URL: https://externals.io/message/93959#93983 · In reply to: #93975
>
> I think as this is a BC break it should require the 2/3 majority. I do
> support fixing the RNGs though.
>
Sure if there's a consensus on that, I have no problem with it.
Have you done any checks on GitHub etc to see how widespread this usage is?
> I'd like to get some data on that too.
>
I have checked, but it's really difficult to find legitimate use cases of
srand and mt_srand. I spent some time stacking up "NOT xyz" terms in the
search, and still didn't find anything that actually relied on
deterministic streams of numbers.
---
## #93986 — Tom Worster — 2016-06-14T23:08:28+00:00
URL: https://externals.io/message/93959#93986 · In reply to: #93959
> The RFC can be found here: https://wiki.php.net/rfc/rng_fixes
Hi Leigh,
Thanks for putting this together. I am strongly pro on two points and
moderately contra on the other two. I'd prefer separated votes, even
though I don't have a vote. I numbered the 4 bullets in your intro 1 thru 4.
4. Insecure usage. I think we should replace the internal insecure uses
of php_rand(). I can't see a reason not to.
3. Poor scaling of bounded outputs. I think RAND_RANGE() should be
fixed. Users surely expect unbiased distribution. There's a BC argument
but the bug is pretty serious. I think this should apply to `array_rand()`
too.
1. Incorrect implementations.
I don't think we should dictate that programs currently using `mt_rand()`
shall use in future use MT19937 any more than we should dictate that
XorShift64 or any other PRNG better fits their requirements.
The incorrectness of the `mt_rand()` implementation with respect to its
documentation can be fixed either in the code or in the docs. Given
that, as far as we know, `mt_rand()`'s byte-stream looks like a decent
PRNG[1] it's not clear that the actual MT19937 sequence is more
important that backward compatibility. I for one think it's very unlikely.
[1] https://gist.github.com/tom--/a12175047578b3ae9ef8
I also don't think we should assume the responsibility of correcting
people's insecure programs using `rand()` or `mt_rand()` (e.g. for keys,
IVs, salts) by changing the algorithm. Programs this bad need more
rework than we can provide. These functions have had scary-colored
cautions on them for a long time.
2. Roughly the same arguments applies to `rand()`. The function is PHP's
API to the OS's rand(3). There's value to that and probably people who
rely on it.
Summarizing 2. and 3. it's not clear what we fix in the real world with
the proposed changes to `rand()` and `mt_rand()`. But I do see BC breakage.
I would prefer to fix these bugs the docs.
With respect to PRNGs completely new to PHP (you mentioned Xoroshiro128+
and PCG), I would prefer completely divorce this question from the bugs
discussed above. If some PHP users need efficient implementations of
such algorithms then I would urge whoever wants to write them to use a
new API and to provide them via PECL. In software, "better" is always
with respect to context. While there are specific, well-known uses for
random numbers (e.g. crypto) where we can make recommendations, in
general we cannot.
Tom
---
## #93988 — Tom Worster — 2016-06-14T23:15:24+00:00
URL: https://externals.io/message/93959#93988 · In reply to: #93962
> Why do we need so many functions to get a random int anyways if we now
> have `random_int()`?
For backwards compatibility. There are programs that use these and
little to gain from breaking them.
Tom
---
## #93989 — Tom Worster — 2016-06-14T23:30:41+00:00
URL: https://externals.io/message/93959#93989 · In reply to: #93972
> Call me ignorant but is this required in typical web applications?
PHP is used for various things, not just web apps. I use it for various
other things because its the language in which I am most fluent.
And the requirements of *typical* apps using PHP should not be the basis
for removing functions that are in fact used in existing programs.
It's possible to change programs so they don't use `mt_rand()` etc. but
most people won't thank you for forcing them to rewrite software that works.
Leigh, iiuc, is trying to fix bugs. Let's not change the discussion to
cleaning up PHP's API.
Tom
---
## #93992 — Yasuo Ohgaki — 2016-06-15T03:19:28+00:00
URL: https://externals.io/message/93959#93992 · In reply to: #93959
Hi Leigh,
>
> The issues I want to bring up for discussion are.
>
> * Replacing `mt_rand()` and `rand()` to a strong, modern RNG.
> * Alternatively, fixing the current `mt_rand()` implementation to make it
> standard
> * Aliasing `rand()` to `mt_rand()` to improve output and cross-platform support
> * Fixing RAND_RANGE for large ranges.
> * Replacing insecure uses of php_rand() with php_random_bytes()
> * Making the `array_rand()` algorithm more efficient
>
> The RFC can be found here: https://wiki.php.net/rfc/rng_fixes
+1 in general.
There should be a way to produce compatible random sequences for
compatibility for reasonable periods, 5+ years at least. IMHO. INI
switch for this is required.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
---
## #93996 — Pierre Joye — 2016-06-15T10:33:35+00:00
URL: https://externals.io/message/93959#93996 · In reply to: #93959
> Hey Internals,
>
> I realise I'm cutting it close with this one, but I want to propose some
> changes to our standard random number generators.
>
> The downside of this proposal is that our RNGs (rand() and `mt_rand()`) are
> seedable and reproduce identical streams (platform dependant) for any given
> seed. However their implementations are broken or inconsistent, so we need
> to weigh up the cost of changing these sequences versus having solid
> implementations.
>
> It is my opinion that if we are going to make any changes to these
> functions, we should make all of the changes at the same time and avoid any
> future disruption to their output.
>
> The RFC contains a few proposals, some of them depend on each other while
> others are standalone. Throughout the discussion phase I hope to reduce the
> number of proposals down to a consensus we can vote on in two weeks time.
>
> I will release a patch when I have a better feeling for the direction we
> want to take.
>
> The issues I want to bring up for discussion are.
>
> * Replacing `mt_rand()` and `rand()` to a strong, modern RNG.
I do not think this is a good option, if by strong you mean another kind of RNG.
> * Alternatively, fixing the current `mt_rand()` implementation to make it
> standard
That sounds more reasonable. An option (please no ini as it is a
programatic flow feature, not a php configuration problem) to keep the
old behavior for BC. Having to add an option for 7.1 or 7.2+ is
reasonable enough for the cases where the current seed and predictable
sequences are desired (same data generations for example using one
seed for example).
> * Replacing insecure uses of php_rand() with php_random_bytes()
> * Making the `array_rand()` algorithm more efficient
Indeed
> The RFC can be found here: https://wiki.php.net/rfc/rng_fixes
>
> If anyone knows of other fixes that should be made at the same time but I
> have overlooked, please let me know so I can get them included.
Also in the replies to this thread I see the word "crypto" mixed with
mt_rand/rand. It does not make sense to me. I agree that some apps
misused these functions as crypto safe RNG, some may even work around
issues and do not want to change their code to use reliable
alternatives. However this is a documentation/education issue. There
is no need to make mt_rand/rand crypto safe but there is a use for a
reliable implemantion of mt_rand.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
---
## #94000 — Christoph Becker — 2016-06-15T11:01:58+00:00
URL: https://externals.io/message/93959#94000 · In reply to: #93972
>
>
> > […]
>
> Call me ignorant but is this required in typical web applications?
> Couldn't we move this functionality to PECL? I mean, it is required in
> games but other than that.
I don't know, but I can image that it is (test suites come to mind). Of
course, it might be an option to move the functionality to PECL, but on
the other hand, what would we gain? For users, however, that might be a
major pain; consider software which runs on shared hosting.
--
Christoph M. Becker
---
## #94002 — Christoph Becker — 2016-06-15T11:11:11+00:00
URL: https://externals.io/message/93959#94002 · In reply to: #93986
>
>
> > […]
>
> Thanks for putting this together. I am strongly pro on two points and
> moderately contra on the other two. I'd prefer separated votes, even
> though I don't have a vote. I numbered the 4 bullets in your intro 1
> thru 4.
>
> 4. Insecure usage. I think we should replace the internal insecure uses
> of php_rand(). I can't see a reason not to.
>
> 3. Poor scaling of bounded outputs. I think RAND_RANGE() should be
> fixed. Users surely expect unbiased distribution. There's a BC argument
> but the bug is pretty serious. I think this should apply to `array_rand()`
> too.
>
> 1. Incorrect implementations.
>
> I don't think we should dictate that programs currently using `mt_rand()`
> shall use in future use MT19937 any more than we should dictate that
> XorShift64 or any other PRNG better fits their requirements.
>
> The incorrectness of the `mt_rand()` implementation with respect to its
> documentation can be fixed either in the code or in the docs. Given
> that, as far as we know, `mt_rand()`'s byte-stream looks like a decent
> PRNG[1] it's not clear that the actual MT19937 sequence is more
> important that backward compatibility. I for one think it's very unlikely.
>
> [1] https://gist.github.com/tom--/a12175047578b3ae9ef8
>
> I also don't think we should assume the responsibility of correcting
> people's insecure programs using `rand()` or `mt_rand()` (e.g. for keys,
> IVs, salts) by changing the algorithm. Programs this bad need more
> rework than we can provide. These functions have had scary-colored
> cautions on them for a long time.
>
> 2. Roughly the same arguments applies to `rand()`. The function is PHP's
> API to the OS's rand(3). There's value to that and probably people who
> rely on it.
Hm, at least traditionally the `rand()` implementation on Windows is
limited to non-negative short ints (16-bit signed), what appears
generally limited, and might make it hard to write portable code. On
the other hand a developer could use `mt_rand()` instead, and we could
document that `rand()` is a rather low-level non-portable API.
> Summarizing 2. and 3. it's not clear what we fix in the real world with
> the proposed changes to `rand()` and `mt_rand()`. But I do see BC breakage.
> I would prefer to fix these bugs the docs.
>
>
> With respect to PRNGs completely new to PHP (you mentioned Xoroshiro128+
> and PCG), I would prefer completely divorce this question from the bugs
> discussed above. If some PHP users need efficient implementations of
> such algorithms then I would urge whoever wants to write them to use a
> new API and to provide them via PECL. In software, "better" is always
> with respect to context. While there are specific, well-known uses for
> random numbers (e.g. crypto) where we can make recommendations, in
> general we cannot.
I agree to every said (except where noted).
--
Christoph M. Becker
---
## #94004 — Tom Worster — 2016-06-15T12:41:15+00:00
URL: https://externals.io/message/93959#94004 · In reply to: #93996
> > […]
> That sounds more reasonable. An option (please no ini as it is a
> programatic flow feature, not a php configuration problem) to keep the
> old behavior for BC. Having to add an option for 7.1 or 7.2+ is
> reasonable enough for the cases where the current seed and predictable
> sequences are desired (same data generations for example using one
> seed for example).
>
Hi Pierre,
I'm glad you mentioned a compatibility mode. Let's say we would offer:
int mt_rand ( $mode = MT_RAND_COMPAT )
int mt_rand ( int $min, int $max, $mode = MT_RAND_COMPAT )
MT_RAND_COMPAT = 1
MT_RAND_MT19937 = 2
A PHP user needs to make the right choice of what to use in their
situation. A technical description of the modes would be confusing and
unhelpful to most users. I have no idea how to document this simply,
honestly and accurately, and without jumping to conclusions about
suitability.
This is why I think a compat/correct mode switch doesn't improve PHP.
It's inconsistent with the spirit set out in the preamble of "PHP RFC:
Your Title Here"[1].
[1] https://wiki.php.net/rfc/template
Similarly, the $mode arg allows us to add MT_RAND_XOROSHIRO128_PLUS or
whatever (interesting to some of us, more "modern", perhaps arguably
more "strong" or are otherwise "better") aren't improvements to PHP
unless users are asking for them.
Tom
---
## #94006 — Jordi Boggiano — 2016-06-15T13:04:36+00:00
URL: https://externals.io/message/93959#94006 · In reply to: #94004
> int mt_rand ( $mode = MT_RAND_COMPAT )
>
> int mt_rand ( int $min, int $max, $mode = MT_RAND_COMPAT )
>
> MT_RAND_COMPAT = 1
>
> MT_RAND_MT19937 = 2
>
> A PHP user needs to make the right choice of what to use in their
> situation. A technical description of the modes would be confusing and
> unhelpful to most users. I have no idea how to document this simply,
> honestly and accurately, and without jumping to conclusions about
> suitability.
>
> This is why I think a compat/correct mode switch doesn't improve PHP.
> It's inconsistent with the spirit set out in the preamble of "PHP RFC:
> Your Title Here"[1].
>
> [1] https://wiki.php.net/rfc/template
>
> Similarly, the $mode arg allows us to add MT_RAND_XOROSHIRO128_PLUS or
> whatever (interesting to some of us, more "modern", perhaps arguably
> more "strong" or are otherwise "better") aren't improvements to PHP
> unless users are asking for them.
Just a thought here, if the goal is to provide a better interface,
wouldn't it be better to use OO for this? Not because OO is better, but
because it would avoid having problems if two mt_rand-using pieces of
code are executed concurrently.
Something like this:
$gen1 = new SeededRandom(MT_RAND_MT19937, 23);
$gen2 = new SeededRandom(MT_RAND_MT19937, 23);
$gen1->rand(); // or get()? generate()?
$gen1->rand();
$gen2->rand(); // returns the same as the first call as both use seed 23
With the current situation, if you add a library that relies on mt_rand
you can suddenly break your ability to get consistent numbers.
Cheers
--
Jordi Boggiano
@seldaek - http://seld.be
---
## #94012 — Tom Worster — 2016-06-15T14:15:09+00:00
URL: https://externals.io/message/93959#94012 · In reply to: #94006
> Just a thought here, if the goal is to provide a better interface,
Hi Jordi,
Iiuc, Leigh's goal, which I support, is to fix known bugs. It is not to
provide a better interface.
I already suggested that if people want new RNGs or a new API then we
should divorce that discussion from the bug fixes. Let's not use this
RFC or thread for that.
Tom
---
## #94021 — Fleshgrinder — 2016-06-15T17:55:12+00:00
URL: https://externals.io/message/93959#94021 · In reply to: #93989
>
>
> > […]
>
> PHP is used for various things, not just web apps. I use it for various
> other things because its the language in which I am most fluent.
>
> PHP is and should remain: a pragmatic web-focused language
>
> --- Rasmus Lerdorf
Please do not ignore our mission statement here. PHP is not a general
purpose language and even real general purpose languages do not offer
predictable RNGs.
> And the requirements of *typical* apps using PHP should not be the basis
> for removing functions that are in fact used in existing programs.
>
Moving to PECL is not considered a BC and people are easily able to get
the functions back in if they really need to.
> It's possible to change programs so they don't use `mt_rand()` etc. but
> most people won't thank you for forcing them to rewrite software that
> works.
>
The applications and libraries who are using it incorrectly right now
will thank us for making it harder to use the language incorrectly.
> Leigh, iiuc, is trying to fix bugs. Let's not change the discussion to
> cleaning up PHP's API.
>
This is not what my proposal is about. I would move all the broken and
weak stuff to PECL and offer the already existing good alternatives to
the developers. At the same time we are able to fix the problems in the
PECL modules and release a new major version of those packages.
We do not need to fix `password_hash()` nor `random_int()` since they work
and they are what is needed in a web-focused language.
--
Richard "Fleshgrinder" Fussenegger
---
## #94024 — Niklas Keller — 2016-06-15T19:31:27+00:00
URL: https://externals.io/message/93959#94024 · In reply to: #94021
Fleshgrinder schrieb am Mi., 15. Juni 2016, 19:55:
>
> > […]
>
> > […]
>
> Please do not ignore our mission statement here. PHP is not a general
> purpose language and even real general purpose languages do not offer
> predictable RNGs.
>
Quoting from PHP.net:
PHP is a popular general-purpose scripting language that is especially
suited to web development.
> > […]
>
> Moving to PECL is not considered a BC and people are easily able to get
> the functions back in if they really need to.
>
>
> > […]
>
> The applications and libraries who are using it incorrectly right now
> will thank us for making it harder to use the language incorrectly.
>
>
> > […]
>
> This is not what my proposal is about. I would move all the broken and
> weak stuff to PECL and offer the already existing good alternatives to
> the developers. At the same time we are able to fix the problems in the
> PECL modules and release a new major version of those packages.
>
> We do not need to fix `password_hash()` nor `random_int()` since they work
> and they are what is needed in a web-focused language.
>
> --
> Richard "Fleshgrinder" Fussenegger
---
## #94025 — Fleshgrinder — 2016-06-15T19:43:05+00:00
URL: https://externals.io/message/93959#94025 · In reply to: #94024
> Quoting from PHP.net:
>
> PHP is a popular general-purpose scripting language that is especially
> suited to web development.
>
Quoting from Wikipedia:
> PHP is a server-side scripting language designed for web development >
but also used as a general-purpose programming language.
But let use stop that now. I already wrote that someone should come up
with use cases for predictable random numbers other than creating
insecure secrets. This is the main problem that needs solving, people
using this stuff without knowing what they do.
Keep in mind that anyone or anything (company) that requires predictable
random numbers for their software (e.g. game) wants to have more control
over distribution and ways to tweak it. Hence, they will directly
implement it straight on their own anyways. Business rules are more
important in such domains than readily available built-in stuff.
Otherwise many people would not have jobs. :P
If they really don't want to they can still fall back to PECL. I really
do not see the shared hosting as a big argument here because shared
hosting directly falls back to web application and -- as I said before
-- in this context the requirement for predictable random numbers is
pretty much nil.
Just proof me wrong and show me where it is needed.
Drupal? Symfony? Zend? Wordpress? PhpBB? ...?
--
Richard "Fleshgrinder" Fussenegger
---
## #94030 — Pierre Joye — 2016-06-16T02:21:46+00:00
URL: https://externals.io/message/93959#94030 · In reply to: #94025
>
>
> > […]
>
> Quoting from Wikipedia:
>
> > […]
> but also used as a general-purpose programming language.
>
> But let use stop that now. I already wrote that someone should come up
> with use cases for predictable random numbers other than creating
> insecure secrets. This is the main problem that needs solving, people
> using this stuff without knowing what they do.
>
> Keep in mind that anyone or anything (company) that requires predictable
> random numbers for their software (e.g. game) wants to have more control
> over distribution and ways to tweak it. Hence, they will directly
> implement it straight on their own anyways.
No they don't all do it.
There are ways to achieve what you want in a nice way while not breaking
things. Let consider them.
Cheers,
Pierre
---
Next page: https://externals.io/message/93959.md?page=2