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 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. > 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
signature.asc
Description: OpenPGP digital signature
