From: Nicholas Clark Date: Fri, 21 Dec 2007 12:09:04 +0000 (+0000) Subject: Update the hash documentation to reflect the changes between 5.8.1 and X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=22883ac550dc5dbe0c35890635d3c37c4084f3a1;p=p5sagit%2Fp5-mst-13.2.git 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 --- diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod index a779b3b..dd38cfd 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 or C 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). 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 0068d7c..6c267b5 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 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, and the ordering has already changed several times during the lifetime of