Change 20141 by [EMAIL PROTECTED] on 2003/07/11 00:27:41
Integrate:
[ 20137]
Retract the statements.
[ 20138]
More retraction.
[ 20139]
New order of seed.
Affected files ...
... //depot/maint-5.8/perl/INSTALL#13 integrate
... //depot/maint-5.8/perl/pod/perlfunc.pod#28 integrate
... //depot/maint-5.8/perl/pod/perlrun.pod#25 integrate
... //depot/maint-5.8/perl/pod/perlsec.pod#6 integrate
Differences ...
==== //depot/maint-5.8/perl/INSTALL#13 (text) ====
Index: perl/INSTALL
--- perl/INSTALL#12~19891~ Mon Jun 30 02:39:29 2003
+++ perl/INSTALL Thu Jul 10 17:27:41 2003
@@ -849,12 +849,12 @@
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. 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.
+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.
B<Perl has never guaranteed any ordering of the hash keys>, and the
ordering has already changed several times during the lifetime of
==== //depot/maint-5.8/perl/pod/perlfunc.pod#28 (text) ====
Index: perl/pod/perlfunc.pod
--- perl/pod/perlfunc.pod#27~20067~ Mon Jul 7 22:39:14 2003
+++ perl/pod/perlfunc.pod Thu Jul 10 17:27:41 2003
@@ -1269,9 +1269,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
-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
@@ -2322,9 +2320,7 @@
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,
@@ -6225,9 +6221,7 @@
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>.
==== //depot/maint-5.8/perl/pod/perlrun.pod#25 (text) ====
Index: perl/pod/perlrun.pod
--- perl/pod/perlrun.pod#24~20136~ Thu Jul 10 17:05:20 2003
+++ perl/pod/perlrun.pod Thu Jul 10 17:27:41 2003
@@ -1102,19 +1102,20 @@
=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 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.
+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.
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.
-This means that each different run of Perl will have a different
-ordering of the results of keys(), values(), and each().
+
+The seed being set 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.
==== //depot/maint-5.8/perl/pod/perlsec.pod#6 (text) ====
Index: perl/pod/perlsec.pod
--- perl/pod/perlsec.pod#5~19891~ Mon Jun 30 02:39:29 2003
+++ perl/pod/perlsec.pod Thu Jul 10 17:27:41 2003
@@ -404,18 +404,14 @@
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.
+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.
-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).
+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
End of Patch.
