To those writing programming language benchmarks: Stop benchmarking rand(). You are hurting security by penalizing default CSPRNG use.
readelf | grep rand. There are NOT thousands of FOSS projects using rand where they need a csPRNG.
-
-
right. you have all opensource programs compiled and greppable on your machine. I did not say THOUSANDS of FOSS using rand. I said THOUSANDS of trivial security holes. Not all of them are related to rand. I'm talking about scaling. Any individual check is basically trivial.
-
... but still, there are THOUSANDS of opensource projects that fail those basic security checks. Explain that away, if it's such a simple problem to solve. At least, we are taking steps. Yep, even when it flies in the face of ISO, which is frankly, not that helpful.
-
this looks so much like the strlcpy all over again. Just because 1% of coders know how to handle strings safely without strlcpy does NOT mean tweaking things for the 99% is not a good idea.
-
Adding a useless function is a non-breaking change. Not comparable to breaking an existing one.
-
Removal of gets was good because it clearly has no valid uses. rand() and mktemp() both have lots of valid uses.
-
In the end, you don't get the big picture. We're doing the changes, we're validating the results, which includes fixing whatever breaks. The cost of fixing visible breakage is waaaay lower than keeping around silent security holes.
-
Putting
#pragma poison for rand in default env & requiring manual override would have solved the problem without silent wrong behavior. -
show us practical examples of wrong behavior, please. Not theoretical discussion. Actual programs that already exist that break silently and that we haven't fixed. As opposed to actual programs that were silently broken and that our change fixed.
- 13 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.