Re: [PHP-DEV] [RFC] RNG fixes

On Jun 29, 2016 10:03 PM, "Leigh" wrote: > > I think I've caught up on everything discussed now. > > One thing I would like to point out, when people have searched for > "legitimate uses" of mt_rand(), you should have been looking for > legitimate uses of mt_srand() - this is the functionality tha

Re: [PHP-DEV] [RFC] RNG fixes

I think I've caught up on everything discussed now. One thing I would like to point out, when people have searched for "legitimate uses" of mt_rand(), you should have been looking for legitimate uses of mt_srand() - this is the functionality that will be broken. On 16 June 2016 at 03:21, Pierre J

Re: [PHP-DEV] [RFC] RNG fixes

Hi! Appropriate picture for the discussion: http://classicprogrammerpaintings.com/post/146500799829/theoretical-computer-scientists-arguing-about -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] RNG fixes

On Fri, Jun 24, 2016 at 8:35 AM, Pierre Joye wrote: > hi, > > On Thu, Jun 23, 2016 at 11:56 PM, Stanislav Malyshev > wrote: >> Hi! >> >>> I would prefer something like random_fast_int() == mt_rand() == rand(), >>> with clear documentation on when to use random_fast_int() instead of >>> random_int

Re: [PHP-DEV] [RFC] RNG fixes

hi, On Thu, Jun 23, 2016 at 11:56 PM, Stanislav Malyshev wrote: > Hi! > >> I would prefer something like random_fast_int() == mt_rand() == rand(), >> with clear documentation on when to use random_fast_int() instead of >> random_int(), and a note on the others that "since 7.2, mt_rand() is an >>

Re: [PHP-DEV] [RFC] RNG fixes

On 6/23/2016 6:56 PM, Stanislav Malyshev wrote: > Hi! > >> I would prefer something like random_fast_int() == mt_rand() == rand(), >> with clear documentation on when to use random_fast_int() instead of >> random_int(), and a note on the others that "since 7.2, mt_rand() is an >> alias for random_

Re: [PHP-DEV] [RFC] RNG fixes

On 6/23/16 12:56 PM, Stanislav Malyshev wrote: Hi! I would prefer something like random_fast_int() == mt_rand() == rand(), with clear documentation on when to use random_fast_int() instead of random_int(), and a note on the others that "since 7.2, mt_rand() is an alias for random_fast_int()" et

Re: [PHP-DEV] [RFC] RNG fixes

On 6/22/2016 11:04 PM, Dan Ackroyd wrote: > On 22 June 2016 at 18:46, Fleshgrinder wrote: >> >> Maybe we could do some name brain storming? > > I would strongly recommend instead of that, sending fewer emails to > this list, with each email containing well thought through ideas. > > Throwing out

Re: [PHP-DEV] [RFC] RNG fixes

Hi! > I would prefer something like random_fast_int() == mt_rand() == rand(), > with clear documentation on when to use random_fast_int() instead of > random_int(), and a note on the others that "since 7.2, mt_rand() is an > alias for random_fast_int()" etc. (Not wedded to the name > random_fast_i

Re: [PHP-DEV] [RFC] RNG fixes

On 23/06/2016 14:57, Nikita Popov wrote: Whatever we do, please maintain the invariant that mt_rand() >= rand() in terms of quality. I recommend doing this by making mt_rand() == rand(). The relationship that I feel is poorly defined at the moment is random_int() vs mt_rand(). There isn't actu

Re: [PHP-DEV] [RFC] RNG fixes

On Thu, Jun 23, 2016 at 3:18 PM, Tom Worster wrote: > On 6/22/16, 5:19 PM, "Nikita Popov" wrote: > > >I haven't been following this thread, just jumping in to comment on this > >point. My suggestion to deprecate rand() was motivated by the fact that > >rand() produces extremely low quality rando

Re: [PHP-DEV] [RFC] RNG fixes

On 6/22/16, 5:19 PM, "Nikita Popov" wrote: >I haven't been following this thread, just jumping in to comment on this >point. My suggestion to deprecate rand() was motivated by the fact that >rand() produces extremely low quality random numbers on Windows, while at >the same time having the name p

Re: [PHP-DEV] [RFC] RNG fixes

Hi! > I haven't been following this thread, just jumping in to comment on this > point. My suggestion to deprecate rand() was motivated by the fact that > rand() produces extremely low quality random numbers on Windows, while at Why not fix it then? > the same time having the name people are mos

Re: [PHP-DEV] [RFC] RNG fixes

On Wed, Jun 22, 2016 at 7:46 PM, Fleshgrinder wrote: > On 6/21/2016 11:40 PM, Rowan Collins wrote: > > Hi, > > > > I already wrote this message once, but it seems to have evaporated into > > the ether. So apologies if it reappears and this is revealed as a poor > > duplicate of it! > > > > I thin

Re: [PHP-DEV] [RFC] RNG fixes

On 22 June 2016 at 18:46, Fleshgrinder wrote: > > Maybe we could do some name brain storming? I would strongly recommend instead of that, sending fewer emails to this list, with each email containing well thought through ideas. Throwing out random ideas into this mailing list does not seem to le

Re: [PHP-DEV] [RFC] RNG fixes

On 6/21/2016 11:40 PM, Rowan Collins wrote: > Hi, > > I already wrote this message once, but it seems to have evaporated into > the ether. So apologies if it reappears and this is revealed as a poor > duplicate of it! > > I think the push to remove "cruft" would make more sense if the > replaceme

Re: [PHP-DEV] [RFC] RNG fixes

Hi Tom, I'm building a startup (my fourth) and I chose PHP and Laravel to make it work. Use the right tool for the job and what not. I think that you have been trolled (YHBT), you've lost by feeding the troll (YHL). Have a nice day (HAND). Also VIM is better than emacs, carry on with that if

Re: [PHP-DEV] [RFC] RNG fixes

On 6/21/16 3:29 PM, Fleshgrinder wrote: My favorite: The PHP approach seems to be that any crazy behavior is acceptable as long as it's documented. People love raggin' on PHP. It's a virulent meme. It propagates so well in our coder culture because it's easy, it's just provocative enough t

Re: [PHP-DEV] [RFC] RNG fixes

On 6/21/16 3:23 PM, Lester Caine wrote: Can someone explain why I should need 'crypto safe' random numbers when ALL *I* use rand for is to give a random order to content items on the page. I cannot. Something more in sync with the shuffle and array_rand without the need to recode to actuall

Re: [PHP-DEV] [RFC] RNG fixes

On 6/21/16 2:32 PM, Stanislav Malyshev wrote: What is for you "obviously faulty stuff" for literally thousands of people is "code that works". I appreciate that there's a number of new hip randomness tests that mt_rand may not satisfy As far as I can tell https://gist.github.com/tom--/a121750

Re: [PHP-DEV] [RFC] RNG fixes

On 6/21/16, 1:43 PM, "Fleshgrinder" wrote: >Yes, let's ask the users! But we don't do that, we just discuss it here. >Howe could we create such a poll that reaches many people? Maybe Reddit? Perhaps you misunderstand what I intended by leaving the choice to users. If we add a new RNG and keep th

Re: [PHP-DEV] [RFC] RNG fixes

Le mercredi 15 juin 2016, 21:43:05 Fleshgrinder a écrit : > 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 k

Re: [PHP-DEV] [RFC] RNG fixes

Hi, I already wrote this message once, but it seems to have evaporated into the ether. So apologies if it reappears and this is revealed as a poor duplicate of it! On 21/06/2016 18:37, Fleshgrinder wrote: I don't understand the drive to holding on to obviously faulty stuff. Nikic proposed al

Re: [PHP-DEV] [RFC] RNG fixes

On 6/21/2016 10:06 PM, Stanislav Malyshev wrote: > I am sorry, what this link is supposed to illustrate? That if one > doesn't read the docs and uses mt_rand wrong they'd get exactly what it > is supposed to do? Ok, true, and? > > This is an obviously false statement, so obviously that I am confus

Re: [PHP-DEV] [RFC] RNG fixes

Hi! > https://news.ycombinator.com/item?id=9941364 I am sorry, what this link is supposed to illustrate? That if one doesn't read the docs and uses mt_rand wrong they'd get exactly what it is supposed to do? Ok, true, and? >> The PHP approach seems to be that any crazy behavior is acceptable >>

Re: [PHP-DEV] [RFC] RNG fixes

On 6/21/2016 9:23 PM, Lester Caine wrote: > Can someone explain why I should need 'crypto safe' random numbers when > ALL *I* use rand for is to give a random order to content items on the > page. Something more in sync with the shuffle and array_rand without the > need to recode to actually use th

Re: [PHP-DEV] [RFC] RNG fixes

On 6/21/2016 8:32 PM, Stanislav Malyshev wrote: > What is for you "obviously faulty stuff" for literally thousands of > people is "code that works". I appreciate that there's a number of new > hip randomness tests that mt_rand may not satisfy, and there's new and > exciting number generator that we

Re: [PHP-DEV] [RFC] RNG fixes

On 21/06/16 19:32, Stanislav Malyshev wrote: >> I don't understand the drive to holding on to obviously faulty stuff. > What is for you "obviously faulty stuff" for literally thousands of > people is "code that works". I appreciate that there's a number of new > hip randomness tests that mt_rand m

Re: [PHP-DEV] [RFC] RNG fixes

Hi! > I don't understand the drive to holding on to obviously faulty stuff. What is for you "obviously faulty stuff" for literally thousands of people is "code that works". I appreciate that there's a number of new hip randomness tests that mt_rand may not satisfy, and there's new and exciting nu

Re: [PHP-DEV] [RFC] RNG fixes

On 6/21/2016 7:33 AM, Stanislav Malyshev wrote: >> 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). > > This is another problem. So we have OpenSSL, then we have mcrypt, the

Re: [PHP-DEV] [RFC] RNG fixes

On 6/19/2016 11:18 PM, Tom Worster wrote: > Actually I satisfied myself that both MT19937 and PHP's mt_rand() produce > good quality random variates and I posted the evidence behind the belief. > I don't think being slow and inefficient with memory justifies removal or > deprecation (premature opti

Re: [PHP-DEV] [RFC] RNG fixes

On 6/21/2016 11:41 AM, Jordi Boggiano wrote: > On 21/06/2016 06:33, Stanislav Malyshev wrote: >> Hi! >> >>> 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. >> >> I don't understand t

Re: [PHP-DEV] [RFC] RNG fixes

On 21/06/2016 06:33, Stanislav Malyshev wrote: Hi! 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. I don't understand this drive to remove functions and break existing code. What is th

Re: [PHP-DEV] [RFC] RNG fixes

Hi! > 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. I don't understand this drive to remove functions and break existing code. What is the point of it? If you don't like them, don't

Re: [PHP-DEV] [RFC] RNG fixes

On 6/19/16, 12:59 PM, "Fleshgrinder" wrote: >This matches Tom Worster's analysis of mt: it's just crap. :P Actually I satisfied myself that both MT19937 and PHP's mt_rand() produce good quality random variates and I posted the evidence behind the belief. I don't think being slow and inefficient

Re: [PHP-DEV] [RFC] RNG fixes

On 6/19/2016 6:27 PM, Pierre Joye wrote: > I think I gave you plenty of valid usage of MT rand or rand in some > extends. > > And the argument about them being dangerous for crypto is the same for any > other functions. And right, this argument is invalid. > > We do not remove cars from the stree

Re: [PHP-DEV] [RFC] RNG fixes

On Jun 19, 2016 10:50 PM, "Fleshgrinder" wrote: > > On 6/17/2016 7:18 PM, Christoph Becker wrote: > > Consequently, we should remove rot13() as well, see > > . And we shouldn't stop there as > > include(_once), require(_once), file_get_contents() and readfile

Re: [PHP-DEV] [RFC] RNG fixes

On 6/17/2016 7:18 PM, Christoph Becker wrote: > Consequently, we should remove rot13() as well, see > . And we shouldn't stop there as > include(_once), require(_once), file_get_contents() and readfile() bear > the risk of file inclusion vulnerabilities … ;) >

Re: [PHP-DEV] [RFC] RNG fixes

On 16.06.2016 at 20:55, Fleshgrinder wrote: > Education is a hard problem that the whole world is struggling with. We > will never achieve it. We will especially not achieve convincing people > of legacy software to change. Heck, we cannot even convince anyone here > to change legacy stuff. Hence,

Re: [PHP-DEV] [RFC] RNG fixes

On Jun 17, 2016 1:55 AM, "Fleshgrinder" wrote: > > On 6/16/2016 8:14 PM, Pierre Joye wrote: > > Well know you do as I gave you examples of such usages. Their Code not > > public so I cannot give you links. > > > > That's a knockout argument. > > On 6/16/2016 8:14 PM, Pierre Joye wrote: > > I am no

Re: [PHP-DEV] [RFC] RNG fixes

On 6/15/2016 1:01 PM, Christoph Becker wrote: > 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 softwa

Re: [PHP-DEV] [RFC] RNG fixes

On 6/16/2016 8:14 PM, Pierre Joye wrote: > Well know you do as I gave you examples of such usages. Their Code not > public so I cannot give you links. > That's a knockout argument. On 6/16/2016 8:14 PM, Pierre Joye wrote: > I am not sure to follow the legitimate part. There are perfectly legitim

Re: [PHP-DEV] [RFC] RNG fixes

On Wed, 15 Jun 2016 at 14:05 Jordi Boggiano wrote: > 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 concurrentl

Re: [PHP-DEV] [RFC] RNG fixes

On Jun 17, 2016 12:43 AM, "Fleshgrinder" wrote: > > On 6/16/2016 4:21 AM, Pierre Joye wrote: > > No they don't all do it. > > > > We don't know but I will try to find legitimate usages of (mt_)rand. Well know you do as I gave you examples of such usages. Their Code not public so I cannot give you

Re: [PHP-DEV] [RFC] RNG fixes

On 6/16/2016 4:21 AM, Pierre Joye wrote: > No they don't all do it. > We don't know but I will try to find legitimate usages of (mt_)rand. On 6/16/2016 4:21 AM, Pierre Joye wrote: > There are ways to achieve what you want in a nice way while not breaking > things. Let consider them. > Moving t

Re: [PHP-DEV] [RFC] RNG fixes

On Jun 16, 2016 2:43 AM, "Fleshgrinder" wrote: > > On 6/15/2016 9:31 PM, Niklas Keller wrote: > > 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

Re: [PHP-DEV] [RFC] RNG fixes

On 6/15/2016 9:31 PM, Niklas Keller wrote: > 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 genera

Re: [PHP-DEV] [RFC] RNG fixes

Fleshgrinder schrieb am Mi., 15. Juni 2016, 19:55: > On 6/15/2016 1:30 AM, Tom Worster wrote: > > On 6/14/16 3:12 PM, Fleshgrinder wrote: > > > >> 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 > >

Re: [PHP-DEV] [RFC] RNG fixes

On 6/15/2016 1:30 AM, Tom Worster wrote: > On 6/14/16 3:12 PM, Fleshgrinder wrote: > >> 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.

Re: [PHP-DEV] [RFC] RNG fixes

On 6/15/16 9:04 AM, Jordi Boggiano wrote: 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

Re: [PHP-DEV] [RFC] RNG fixes

On 15/06/2016 13:41, Tom Worster wrote: 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

Re: [PHP-DEV] [RFC] RNG fixes

On 6/15/16 6:33 AM, Pierre Joye wrote: > * 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 a

Re: [PHP-DEV] [RFC] RNG fixes

On 14.06.2016 at 21:12, Fleshgrinder wrote: > On 6/14/2016 8:56 PM, Christoph Becker wrote: > >> 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() an

Re: [PHP-DEV] [RFC] RNG fixes

On Tue, Jun 14, 2016 at 11:46 PM, Leigh wrote: > 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 id

Re: [PHP-DEV] [RFC] RNG fixes

Hi Leigh, On Wed, Jun 15, 2016 at 1:46 AM, Leigh wrote: > > 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 impr

Re: [PHP-DEV] [RFC] RNG fixes

On 6/14/16 3:12 PM, Fleshgrinder wrote: 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 PH

Re: [PHP-DEV] [RFC] RNG fixes

On 6/14/16 1:45 PM, Fleshgrinder wrote: 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 -- PHP Internals - PHP Runtime Development Mailing Li

Re: [PHP-DEV] [RFC] RNG fixes

On Tue, 14 Jun 2016 at 20:56 Davey Shafik wrote: > > 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

Re: [PHP-DEV] [RFC] RNG fixes

On Tue, Jun 14, 2016 at 3:56 PM, Davey Shafik wrote: > On Tue, Jun 14, 2016 at 20:13 Fleshgrinder wrote: > > > On 6/14/2016 8:56 PM, Christoph Becker wrote: > > > 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 re

Re: [PHP-DEV] [RFC] RNG fixes

On Tue, Jun 14, 2016 at 20:13 Fleshgrinder wrote: > On 6/14/2016 8:56 PM, Christoph Becker wrote: > > 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 r

Re: [PHP-DEV] [RFC] RNG fixes

On 6/14/2016 8:56 PM, Christoph Becker wrote: > 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_i

Re: [PHP-DEV] [RFC] RNG fixes

On 14.06.2016 at 20:46, Leigh wrote: > On Tue, 14 Jun 2016 at 19:14 Christoph Becker wrote: > >> In my opinion, we need at least one random function which yields >> reproducible values. > > Even with the proposed changes both functions will still be capable of > reproducible sequences, just diff

Re: [PHP-DEV] [RFC] RNG fixes

On Tue, 14 Jun 2016 at 19:14 Christoph Becker wrote: > > 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 diffe

Re: [PHP-DEV] [RFC] RNG fixes

On Tue, 14 Jun 2016 at 18:45 Fleshgrinder wrote: > 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

Re: [PHP-DEV] [RFC] RNG fixes

On 14.06.2016 at 19:45, Fleshgrinder wrote: > On 6/14/2016 6:46 PM, Leigh wrote: >> 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

Re: [PHP-DEV] [RFC] RNG fixes

On 6/14/2016 6:46 PM, Leigh wrote: > 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-pla

Re: [PHP-DEV] [RFC] RNG fixes

On Tue, Jun 14, 2016 at 12:46 PM, Leigh wrote: > 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 i

[PHP-DEV] [RFC] RNG fixes

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. How