Retract the statements.

p4raw-id: //depot/perl@20137

diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod
index daeb6be..08b08af 100644 (file)
--- a/pod/perlfunc.pod
+++ b/pod/perlfunc.pod
@@ -1269,9 +1269,7 @@ element in the hash.
 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
-for security reasons (see L<perlsec/"Algorithmic Complexity Attacks">).
+function would produce on the same (unmodified) hash.
 
 When the hash is entirely read, a null array is returned in list context
 (which when assigned produces a false (C<0>) value), and C<undef> in
@@ -2319,9 +2317,7 @@ Returns a list consisting of all the keys of the named hash.
 The keys 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 the same order as either the C<values> or C<each>
-function produces (given that the hash has not been modified).  Since
-Perl 5.8.1 the ordering is different even between different runs of
-Perl for security reasons (see L<perlsec/"Algorithmic Complexity
+function produces (given that the hash has not been modified).
 Attacks">).
 
 As a side effect, calling keys() resets the HASH's internal iterator,
@@ -6224,9 +6220,7 @@ Returns a list consisting of all the values of the named hash.
 The values 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 the same order as either the C<keys> or C<each>
-function would produce on the same (unmodified) hash.  Since Perl
-5.8.1 the ordering is different even between different runs of Perl
-for security reasons (see L<perlsec/"Algorithmic Complexity Attacks">).
+function would produce on the same (unmodified) hash.
 
 As a side effect, calling values() resets the HASH's internal iterator,
 see L</each>.

diff --git a/pod/perlsec.pod b/pod/perlsec.pod
index 41f9669..ecd9bbc 100644 (file)
--- a/pod/perlsec.pod
+++ b/pod/perlsec.pod
@@ -404,18 +404,14 @@ into account.
 
 In Perls before 5.8.1 one could rather easily generate data that as
 hash keys would cause Perl to consume large amounts of time because
-internal structure of hashes would badly degenerate.  In Perl 5.8.1
-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).
+internal structure of hashes would badly degenerate.  In Perl 5.8.1 it
+is possible to randomly perturb the hash function by a pseudorandom
+seed which makes generating such naughty hash keys harder.  See
+L<perlrun/PERL_HASH_SEED> for more information.
+
+Perturbing the hash ordering affects for example modules like
+Data::Dumper: if one is dumping hashes, the outputs of two different
+runs are no more identical.
 
 B<Perl has never guaranteed any ordering of the hash keys>, and the
 ordering has already changed several times during the lifetime of