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 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. >
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 fancied > 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 it > 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 none > of them requires removal of functions and syntax. > 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. > 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. > 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. > 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. > 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: > > https://github.com/zendframework/zf1/blob/210190dab599e2897220648c9040bce9ff76f21f/library/Zend/Captcha/Image.php#L407 > https://github.com/zendframework/zf1/blob/210190dab599e2897220648c9040bce9ff76f21f/library/Zend/Amf/Value/Messaging/AbstractMessage.php#L82 > https://github.com/zendframework/zend-cache/blob/bb8a75c62d3e1c75b8d8bc53f8b2db98314d3a17/src/Storage/Plugin/OptimizeByFactor.php#L42 > 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. > > 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 which > randomness to use in which context. > 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: > > 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. > 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 in > Germany. So whoever considers it beneath them because it has mt_rand can > 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. > 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. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
