Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94183 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78943 invoked from network); 21 Jun 2016 20:53:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Jun 2016 20:53:19 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.86 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 77.244.243.86 mx105.easyname.com Received: from [77.244.243.86] ([77.244.243.86:36284] helo=mx207.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 78/36-43024-D39A9675 for ; Tue, 21 Jun 2016 16:53:17 -0400 Received: from cable-81-173-134-219.netcologne.de ([81.173.134.219] helo=[192.168.178.20]) by mx.easyname.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bFSfI-0003NJ-Hu; Tue, 21 Jun 2016 20:52:57 +0000 Reply-To: internals@lists.php.net References: <2f92fa26-5f50-0e68-c1fc-de79f17c201e@fleshgrinder.com> <8e046aae-b87b-6c6d-da41-986f8ad9aa54@gmail.com> To: Stanislav Malyshev , internals@lists.php.net Message-ID: <6627f910-71c3-d7d0-bf96-18130ddedfc4@fleshgrinder.com> Date: Tue, 21 Jun 2016 22:53:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CeQ83aDIlbj1p8OErRVg7MVc6Vau7dmhO" X-ACL-Warn: X-DNSBL-BARRACUDACENTRAL Subject: Re: [PHP-DEV] [RFC] RNG fixes From: php@fleshgrinder.com (Fleshgrinder) --CeQ83aDIlbj1p8OErRVg7MVc6Vau7dmhO Content-Type: multipart/mixed; boundary="FUFAeExWimBtOb1e8xhAmNlKN4qnCwO90" From: Fleshgrinder Reply-To: internals@lists.php.net To: Stanislav Malyshev , internals@lists.php.net Message-ID: <6627f910-71c3-d7d0-bf96-18130ddedfc4@fleshgrinder.com> Subject: Re: [PHP-DEV] [RFC] RNG fixes References: <2f92fa26-5f50-0e68-c1fc-de79f17c201e@fleshgrinder.com> <8e046aae-b87b-6c6d-da41-986f8ad9aa54@gmail.com> In-Reply-To: --FUFAeExWimBtOb1e8xhAmNlKN4qnCwO90 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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? >=20 > This is an obviously false statement, so obviously that I am confused > about the purpose which could drive you to quote it. Unless it claims > that this is not actual approach but just "seems" to be to some person > on the internet. In which case I wonder why should I care about > obviously false impression of some person on the internet. >=20 It is meant to illustrate that people do not read the docs and that people get it wrong. I still claim that this indicates room for improvement on our side. On 6/21/2016 10:06 PM, Stanislav Malyshev wrote: > There's plenty of any stuff found on the Internet. So what? If I fancie= d > to read only "PHP sucks" articles every day, I could probably occupy > myself full-time for months without reading any of them twice. 90% of i= t > is hair-splitting and "I didn't read the manual and it's your fault" > kind of stuff, 10% of it are real issues. Which are known to us and non= e > of them requires removal of functions and syntax. >=20 We both could waste our time with that or try to improve PHP (you probably more than me but I am just starting to invest more time into this and hope to get more useful in the future). Randomly removing functions and syntax does not help -- no question there -- but selectively cleaning things up definitely does. Or why do you think that there are so many internals threads and RFCs discussing exactly that. I know that you have the impression of me that I always just want to remove everything but we also were in various threads were I was of an opposite opinion. However, it is true that I generally tend to go more into the direction of clean-up rather than simply keeping and ignoring something. On 6/21/2016 10:06 PM, Stanislav Malyshev wrote: > Nobody argues with doing better. But "let's remove this function > altogether because it has a corner case" is not doing better, that's > exactly my point. >=20 Then let's stop discussing that point and try to do better together. ;) I will ignore all the Hacker News stuff you wrote because it obviously goes into a completely different direction than intended on my side. Sorry for confusing you. On 6/21/2016 10:06 PM, Stanislav Malyshev wrote: > True. But we *want* them to upgrade. And needlessly removing stuff > prevents that. >=20 Yes to the fact that we want the upgrades and that needless removals will not help. I however stick to the believe that selective removals do.= On 6/21/2016 10:06 PM, Stanislav Malyshev wrote: > Generic and thus meaningless in the specific context, without > qualification at least. It's just a pejorative. "It needs to be removed= > because it's bad". It's not argument for removal, it's just > restating the same. >=20 The arguments are in the thread (not in my answer to you). On 6/21/2016 10:06 PM, Stanislav Malyshev wrote: > That is based on what? I certainly have seen a lot of rand usage having= > little to nothing to do with cryptography. >=20 Open source code, issues, and pull requests that I searched through on GitHub. On 6/21/2016 10:06 PM, Stanislav Malyshev wrote: > I found three usages within 5 minutes having nothing to do with crypto:= >=20 > https://github.com/zendframework/zf1/blob/210190dab599e2897220648c9040b= ce9ff76f21f/library/Zend/Captcha/Image.php#L407 > https://github.com/zendframework/zf1/blob/210190dab599e2897220648c9040b= ce9ff76f21f/library/Zend/Amf/Value/Messaging/AbstractMessage.php#L82 > https://github.com/zendframework/zend-cache/blob/bb8a75c62d3e1c75b8d8bc= 53f8b2db98314d3a17/src/Storage/Plugin/OptimizeByFactor.php#L42 >=20 None of them is using rand() :P On 6/21/2016 10:06 PM, Stanislav Malyshev wrote: > That's not the meaning of "impossible" I'm used to. >=20 > The very fact that you claim rand is not used by anything but crypto > suggests to me that you are overfocusing on one issue - which is a real= > issue, no doubt about it - of using non-crypto-strong randomness in > crypto context and ignoring other aspects where randomness is in play. > Solving your problem neither requires removing mt_rand nor is achieved > by it. The solution would be better crypto API and education about whic= h > randomness to use in which context. >=20 I think you are still misunderstanding where I would like to go with all of this, probably because you did not read all of the thread or because my messages do not contain the relevant information or I need to simply improve with my writing skills. Recap: I proposed to deprecate pretty much all of the functions and people directly reacted with panic. Initially I was like, what the?!? but I got the point and agreed that there should be one non-crypot rand function. I already mentioned to you that I had a closer look at the various cool new random algorithms and that none of them seems fit for production yet. So where is my proposal at right now? Nice of you to ask instead of simply continuing the discussion on various philosophical topics where my answers are going to be super biased by my personal opinion and usually nobody has the right answer anyways. My current proposal would be to not touch any of the existing functions because that would be a BC in our current 7 branch. Invest some time and see how PCG matures since it looks like the most promising algorithm of the ones available to us as of today. If it matures enough, implement it as the algo that rand() uses instead of forwarding it to the operating system in PHPng. Deprecate mt_rand() in favor of rand() in the same release. Remove mt_rand() in PHPnng so that there is only one non-crypto random function left within PHP. Of course it would also be possible to alias mt_rand() to rand() in PHPnng with an E_NOTICE or E_WARNING and remove it in PHPnnng just to ease the upgrade path further. I would be more than fine with that (as a general approach to such topics). This is not the best approach because most people were asked to migrate from rand() to mt_rand() without any plan to do anything with rand(). Now many people exchanged their rand() with mt_rand() and with the above they would not to change those mt_rand() calls back to rand(). However, mt_rand() has a specific algo in its name which is bad. Usage of the older and more generic rand() name is better to provide forward compatibility in the future and allows us to exchange the underlying algo again if necessary in an future major release of PHP. The only situation were this approach would truly break something is if an application relies on the predictable sequences that are currently produced by rand() (on a specific platform). However, I do not see this as a big problem for a major version to be honest. That would be up to further discussion. That's where I currently stand with my thoughts. Perfect would be to have two functions that are named: 1. random_int() 2. crypto_random_int() However, it might be too late to reach that goal ... :( On 6/21/2016 10:06 PM, Stanislav Malyshev wrote: > Java pretty much never removes APIs. And I don't remember any instance > of Java syntax being removed. See for example: >=20 > https://www.quora.com/Has-Sun-or-Oracle-ever-removed-a-deprecated-Java-= method-in-an-official-API/ > Oracle people say they *consider* to maybe remove some com.sun.* > *internal* APIs that aren't even part of official documented API. From > what I know, these considerations are still just talk. Somehow they are= > not worried about articles on HN and nobody wanting to use Java because= > they have "cruft". > Also, Java never generates runtime messages on deprecated items. >=20 Did not know that they just keep on deprecating. I always update as soon as I encounter something that is deprecated. That approach would bring us back to your question regarding what deprecations are good for if you plan to never remove it. :P On 6/21/2016 10:06 PM, Stanislav Malyshev wrote: > PHP has millions of users and servers, including in Europe, including i= n > Germany. So whoever considers it beneath them because it has mt_rand ca= n > use whatever language they see fit, but I am not very impressed by the > argument that somehow PHP is in a huge crisis and removing stuff that > works somehow is going to help solve it. >=20 Once more, I never said that PHP is in a huge crisis (the opposite is the case) nor that simply removing stuff will help it (selectively cleaning things that are weird or not needed might help to gain even more momentum). I just said that it is much harder to find PHP developers compared to some other languages because PHP is not actively supported through the old school industry as well as universities who look at the old school industry. Just look at the big players that are around in Germany: car manufacturers, SAP, Siemens, ... Most stuff is Java and some times Ruby if it is web related. PHP is left to people who teach themselves at home and they are often lacking the theoretical background when it comes to real coding. --=20 Richard "Fleshgrinder" Fussenegger --FUFAeExWimBtOb1e8xhAmNlKN4qnCwO90-- --CeQ83aDIlbj1p8OErRVg7MVc6Vau7dmhO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXaakwAAoJEOKkKcqFPVVr/LgQAJT1lrrayPqIMtvpV+GHoZsJ 1CyO5ayO7My4uhIy1gxjAXsoZub2x4Z008KSQ8BH9AeWTzEMK/5sllOaKGhW5b5M BNEF20c+1muNaqlwa3tmMF+cc/EngE05cAMzVxIWGHca0Tev7Kdxs178oQOrop93 FL9wkqqYZWaA6IdfHwIdC8Mluj1rlutQsNMbaaIPc51RBUb1BK4wrpeQsP8gluC0 YTUgFfJyQra650Ztl4uscDfRs3CmKvsuEWr3Z+nc9D5wTR4+f3E13X5LKba4O0/5 xwG33SBwJguBe56mvXfLVnFZi1/9xV9oo5Mykwz6lanCuty/MWpwlXjAlaGiEFTJ DoHkTMplj2l3KeGJma7INFMVqdhdIR/1fOe4/JSpa+uTRHOI15A7nxc8ssJxfKfu ayokP0wEtp6xvE3CJrYwMwJokZLaPi+yg666SYLafd7HuXBtc6Ea/QtHScYD5Er4 mqXev4PN0DOKMsgu7tXYR7RMg6lb681bHPH1AOe+vwpEZIunPyz2lge7CLeaO7DB vX14icuVY7GzOUMlCONRBykXBicRbSm8oJbcepNYzJVEVM7VzBcjEXAyv9tU/slt XbMSPL/806SouwT/LO+E30ZqeR2oTAUv27iMkcfARc5/aFe/LzLOTZh9oBAEXjw1 JjW6bMkSr2leQZUENRcq =8SAS -----END PGP SIGNATURE----- --CeQ83aDIlbj1p8OErRVg7MVc6Vau7dmhO--