So what new problem was addressed by the 5.17 changes?I can't remember the full details off the top of my head, but amongst others issues, there was a bug in the 5.8.1 implementation that, with a suitably crafted set of keys, could trigger the hash code into doubling the bucket size for every added key, making it trivial to exhaust a web server's memory. It was also shown that the ordering of keys extracted from a hash (like a web server returning unsorted headers) could be used to determine the server's hash seed.
And has anyone ever seen a plausible demonstration of that "new problem"?On the security list I've seen simple code (that puts a particular sequence of keys into hash) that can crash the perl process.
Has there ever been an reported sighting of anyone exploiting that new problem in the field?That shouldn't be the criteria for fixing security issues.
If the change is so critical, why wasn't it back-ported to 5.10 and other earlier versions that are still being shipped with 95% of *nix distributions?)We backported the relevant changes to all maintained perl versions. It's up to vendors whether they patch old unsupported perl versions if they still ship them.
Dave.
In reply to Re^6: Our perl/xs/c app is 30% slower with 64bit 5.24.0, than with 32bit 5.8.9. Why?
by dave_the_m
in thread Our perl/xs/c app is 30% slower with 64bit 5.24.0, than with 32bit 5.8.9. Why?
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |