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 >> as long as it's documented. 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. > There is plenty more of this stuff to be found on the Internet and > the 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. > only thing I want to show is that it is faulty. It is not broken, > yes, but faulty and hard to use right for many people out there. This > is No, it's not hard to use for most people out there. In fact, it is extremely easy to use to most people out there, which is easily proven by people actually using it in millions. > usually reason enough to react and try to do better. 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. > Why is it faulty? Well, it has many weird edge cases that people need > to learn about. Reading the manual is however not something people > actually do and this results in constant education being necessary. > The question is, why can't we fix that? The answer here seems to be: > because of legacy support. You are saying yourself that nobody is > upgrading anyways If you want to create a random function that would not require knowing anything about randomness and how to use random functions, and still be crypto-strong, and will have no corner cases at all, you will fail. If you want to create a random function that would not have that particular corner case, you will succeed easily. So what? It will have different corner cases. The fact that some guy wrote on HN about this corner case and didn't write about another one changes nothing. We can and should have better random functions. It is not the reason to remove ones that work. Even if they have corner cases which people once talked about on HN. > Not within 7.x because that would be a serious BC within a non-major > version. Of course we would remove rand() in 8.0 in favor of > mt_rand() or a better alternative if readily available within the > versions of PHP that were releases before 8.0. So all the code that uses *rand() is broken, and we have nobody that uses that code upgrading to 8.0 until they have a budget to rewrite and re-test and re-audit all their code, which is probably sometime in the next 20 years. And at the price of that we achieved... what exactly? We certainly didn't help people that used rand() - they are now using unsupported PHP version with all bugs and security issues and can't upgrade. We didn't help people starting new development - they don't need rand() removed, they can just use new stuff. But now we can go back to that HN thread and say "looks at us, we have no cruft anymore!" Big achievement unlocked? > On 6/21/2016 8:32 PM, Stanislav Malyshev wrote: >> The users that do not wish to upgrade just won't upgrade. Making >> them jump through hoops just to have what they already have makes >> no sense. >> > > If they don't upgrade, they don't mind it being removed. ;) True. But we *want* them to upgrade. And needlessly removing stuff prevents that. > Yes, cruft is a generic term: https://en.wikipedia.org/wiki/Cruft 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. > It specifically contains "redundant" which is more than appropriate > to the current discussion since we have two random functions that do > literally the same but one worse than the other. It doesn't have to be worse. > No since most (mt_)rand() calls are broken crypto crap. Just go out > and That is based on what? I certainly have seen a lot of rand usage having little to nothing to do with cryptography. > search for yourself like I did. It is pretty much impossible to find > any other usage ... Not saying that there are not legitimate usages > of any of those functions but they are super rare. 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 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. > It is hard to judge whether the hidden BCs that are silently being > introduced by some RFCs are more harmful than a proper deprecate and > remove approach with proper version numbers. I would argue that the > last approach is better, at least other programming languages have > more success with it (Java). 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. > PHP has a bad reputation among the industry especially in > Europe/Germany because of "the various complains that we all know of > and are already fed up with". This (mt_)rand() situation is just a > super tiny part of the whole. 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. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
