Because of this feature the keys(), values(), and each() functions
may return the hash elements in different order between different
-runs of Perl even with the same data. The additional randomisation
-is enabled if the environment variable PERL_HASH_SEED is set, see
-perlrun for details.
-
-One make the randomisation default by adding -DUSE_HASH_SEED to the
-compilation flags, or completely disable it by adding -DNO_HASH_SEED.
+runs of Perl even with the same data. One can still revert to the old
+repeatable order by setting the environment variable PERL_HASH_SEED,
+see L<perlrun>. Another option is to add -DUSE_HASH_SEED_EXPLICIT to
+the compilation flags, in which case one has to explicitly set the
+PERL_HASH_SEED environment variable to enable the security feature,
+or -DNO_HASH_SEED to completely disable the feature.
B<Perl has never guaranteed any ordering of the hash keys>, and the
ordering has already changed several times during the lifetime of
/* [perl #22371] Algorimic Complexity Attack on Perl 5.6.1, 5.8.0 */
#if !defined(NO_HASH_SEED) && !defined(USE_HASH_SEED) && !defined(USE_HASH_SEED_EXPLICIT)
-# define USE_HASH_SEED_EXPLICIT
+# define USE_HASH_SEED
#endif
#include "regexp.h"
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.
+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">).
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
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).
+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
Attacks">).
As a side effect, calling keys() resets the HASH's internal iterator,
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.
+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">).
As a side effect, calling values() resets the HASH's internal iterator,
see L</each>.
=item PERL_HASH_SEED
(Since Perl 5.8.1.) Used to randomise Perl's internal hash function.
+To emulate the pre-5.8.1 behaviour, set to an integer (zero means
+exactly the same order as 5.8.0). "Pre-5.8.1" means, among other
+things, that hash keys will be ordered the same between different runs
+of Perl.
-The default behaviour is B<not> to randomise if the PERL_HASH_SEED is
-unset. If Perl has been compiled with C<-DUSE_HASH_SEED>, the default
-behaviour B<is> to randomise. If Perl hash been compiled with
-C<-DNO_HASH_SEED>, the hash randomisation is completely disabled.
-
-If PERL_HASH_SEED is set to a numeric (positive integer) string,
-that is used as the seed.
+The default behaviour is to randomise unless the PERL_HASH_SEED is set.
+If Perl has been compiled with C<-DUSE_HASH_SEED_EXPLICIT>, the default
+behaviour is B<not> to randomise unless the PERL_HASH_SEED is set.
If PERL_HASH_SEED is unset or set to a non-numeric string, Perl uses
the pseudorandom seed supplied by the operating system and libraries.
-
-The seed being set means that each different run of Perl will have
-a different ordering of the results of keys(), values(), and each().
+This means that each different run of Perl will have a different
+ordering of the results of keys(), values(), and each().
See L<perlsec/"Algorithmic Complexity Attacks"> for more information.
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 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.
+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).
B<Perl has never guaranteed any ordering of the hash keys>, and the
ordering has already changed several times during the lifetime of
projects / p5sagit/p5-mst-13.2.git / commitdiff