Change 32688 by [EMAIL PROTECTED] on 2007/12/21 12:09:04
Update the hash documentation to reflect the changes between 5.8.1 and
5.8.2, that disabled the automatic randomisation of all hashes.
Affected files ...
... //depot/perl/pod/perlfunc.pod#583 edit
... //depot/perl/pod/perlsec.pod#40 edit
Differences ...
==== //depot/perl/pod/perlfunc.pod#583 (text) ====
Index: perl/pod/perlfunc.pod
--- perl/pod/perlfunc.pod#582~32587~ 2007-12-06 06:21:34.000000000 -0800
+++ perl/pod/perlfunc.pod 2007-12-21 04:09:04.000000000 -0800
@@ -1427,7 +1427,7 @@
order is subject to change in future versions of perl, but it is
guaranteed to be in the same order as either the C<keys> or C<values>
function would produce on the same (unmodified) hash. Since Perl
-5.8.1 the ordering is different even between different runs of Perl
+5.8.2 the ordering can be different even between different runs of Perl
for security reasons (see L<perlsec/"Algorithmic Complexity Attacks">).
When the hash is entirely read, a null array is returned in list context
==== //depot/perl/pod/perlsec.pod#40 (text) ====
Index: perl/pod/perlsec.pod
--- perl/pod/perlsec.pod#39~28800~ 2006-09-07 06:13:05.000000000 -0700
+++ perl/pod/perlsec.pod 2007-12-21 04:09:04.000000000 -0800
@@ -457,13 +457,16 @@
makes generating such naughty hash keys harder.
See L<perlrun/PERL_HASH_SEED> for more information.
-The random perturbation is done by default but if one wants for some
-reason emulate the old behaviour one can set the environment variable
-PERL_HASH_SEED to zero (or any other integer). One possible reason
-for wanting to emulate the old behaviour is that in the new behaviour
-consecutive runs of Perl will order hash keys differently, which may
-confuse some applications (like Data::Dumper: the outputs of two
-different runs are no more identical).
+In Perl 5.8.1 the random perturbation was done by default, but as of
+5.8.2 it is only used on individual hashes if the internals detect the
+insertion of pathological data. If one wants for some reason emulate the
+old behaviour (and expose oneself to DoS attacks) one can set the
+environment variable PERL_HASH_SEED to zero to disable the protection
+(or any other integer to force a known perturbation, rather than random).
+One possible reason for wanting to emulate the old behaviour is that in the
+new behaviour consecutive runs of Perl will order hash keys differently,
+which may confuse some applications (like Data::Dumper: the outputs of two
+different runs are no longer identical).
B<Perl has never guaranteed any ordering of the hash keys>, and the
ordering has already changed several times during the lifetime of
End of Patch.
