summaryrefslogtreecommitdiff
path: root/pod/perlsec.pod
diff options
context:
space:
mode:
authorNicholas Clark <nick@ccl4.org>2007-12-21 12:09:04 +0000
committerNicholas Clark <nick@ccl4.org>2007-12-21 12:09:04 +0000
commit22883ac550dc5dbe0c35890635d3c37c4084f3a1 (patch)
tree7a2496eab62d4d98ca6ead0cdaf4f503b58e6d8c /pod/perlsec.pod
parent644741fd207d1faadeb06a76dbea0c6d069c568b (diff)
downloadperl-22883ac550dc5dbe0c35890635d3c37c4084f3a1.tar.gz
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
Diffstat (limited to 'pod/perlsec.pod')
-rw-r--r--pod/perlsec.pod17
1 files changed, 10 insertions, 7 deletions
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