| [reply] |
Hash randomization broke a lot of CPAN modules that were relying on hash order (usually relying on it in the test suite). These were mostly caught during 5.17.x series, so if you've got recent versions of those modules, you'll be OK.
Amongst the affected distributions were DBI, libwww-perl, Catalyst-Runtime, DBIx-Class, Gtk2, Data-Visitor, PDF-API2, RDF-Trine, Template-Toolkit and Dancer (via MIME-Types). Many of these are major distributions that a lot of other distributions depend on.
package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
| [reply] |
While it is true that much of the fallout of this change related to tests making unwarranted assumptions about hash order, but at least a few real*bugs were found too.
For instance the changes which added the variable and subscript names to uninitialized warnings in an earlier Perl would fail if the key involved was in the last bucket of the hashes bucket array. Prior to hash randomization the tests for this feature would not test this case. With hash randomization they would regularly fail. The bug was fixed, and you now have better uninitialized warnings in 5.18.
IIRC, DBI and CGI were the same story. Real bugs were found and fixed because of hash order randomization. So lets keep a sense of proportion here. Hash randomization makes it easy to identify a class of bugs that is extremely difficult to find any other way.
| [reply] |
That is not the problem; the response to that is.
When considering a breaking change, I was taught to ask three questions:
- Is the breakage actually necessary?
Is the thing being 'fixed' actually manifesting itself in production code.
Has any real-world occurrence of the ACA actually been witnessed or reported?
- If so, can the breakage be limited in scope?
Either by limiting the total breakage; or by selectively applying the breaking fix only when required.
Could the 'fix' have been limited to (say) only when taint was enabled?
- Is the breaking 'fix' the *ONLY* solution to the problem?
Not the first. Not the best. Not the least effort or least worst; but the ONLY?
Is it necessary to randomise all hashes differently?
Wouldn't picking the same random hash initialisation, for all hashes for any given run, have been just as effective at stopping real-world exploits in the wild?
| [reply] |
Check the documentation on PERL_PERTURB_KEYS in perldelta: PERL_PERTURB_KEYS=0 will restore the previous behavior. This should help you to find bugs related to hash randomization.
| [reply]
[d/l]
[select] |
- Yes. Yes. Yes
- No. No. No.
- Only is irrelevant. Only is irrelevant. Yes. No.
| [reply] |