On Jun 17, 2016 1:55 AM, "Fleshgrinder" <p...@fleshgrinder.com> 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 not sure to follow the legitimate part. There are perfectly legitimate > > usage of rand/mt_rand outside crypto. The fact that some developers still > > do not get the non safe part is an education problem. The same applies to > > many functions, like serialize, which has many security impacts but we do > > not remove it because some people misuse it constantly. > > > > Nikic sees it like I do: > > https://wiki.php.net/rfc/deprecations_php_7_1#rand_srand_and_getrandmax
Nothing there says anything about dropping mt_rand or make it mon standard using "modern" algorithms. As I said earlier, to have a std MT implementation is a good thing. I am only not sure about the implications of changing it now by default. > People are already preparing for it: > > https://github.com/SimpleMachines/SMF2.1/issues/3492 > > And apparently people who want to create tiny games don't get it right: > > https://github.com/Frug/AJAX-Chat/issues/167 > > I am still going through the search results. So far everything deals > with broken crypto and invalid usage of rand(), srand() as well as > mt_rand() and mt_srand(). I know you will continue insisting that this > is a super crucial feature just because you started with this argument > into this discussion. I learned that people in general have a hard time > changing their mind a long time ago. Generalities do not apply to people or code. I can change my mind but not about dropping it to improve security as it is the wrong side of the problem. Let me know if my point is not clear (not rejecting the improvements but the drop and default behaviours) but at no point I said it is a "super crucial" feature. I only consider as yet another change that can and will break codes by default does a false sense of security (use php_random for security purposes or the compatibility package). > > A designer knows he has achieved perfection not when there is nothing > > left to add, but when there is nothing left to take away. > > > > --- Antoine de Saint-Exupery > > 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, if rand and friends stay, they will > continue to help people to produce insecure software. > > On 6/16/2016 8:14 PM, Pierre Joye wrote: > > It does as these functions are available by default and cannot be disabled > > (ext/standard). > > > > And? That is beside the point. People can simply add the PECL module and > there is no difference. We could deprecate them and move them to PECL > later. There are many ways. > > Changing the behavior of any of these functions *is* a BC for the > software that you refer to that relies on the predictability of these > functions. Somehow it seems that you are fine with that ...?!? > > -- > Richard "Fleshgrinder" Fussenegger >
