Update the hash documentation to reflect the changes between 5.8.1 and

5.8.2, that disabled the automatic randomisation of all hashes.

p4raw-id: //depot/perl@32688

2 files changed, 11 insertions, 8 deletions

diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod
index a779b3b550..dd38cfdea6 100644
--- a/pod/perlfunc.pod
+++ b/pod/perlfunc.pod
@@ -1427,7 +1427,7 @@ Entries are returned in an apparently random order.  The actual random
 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
diff --git a/pod/perlsec.pod b/pod/perlsec.pod
index 0068d7cad5..6c267b5100 100644
--- a/pod/perlsec.pod
+++ b/pod/perlsec.pod
@@ -457,13 +457,16 @@ the hash function is randomly perturbed by a pseudorandom seed which
 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