Upgrade to Devel::PPPort 3.14

[p5sagit/p5-mst-13.2.git] / pod / perlsec.pod

diff --git a/pod/perlsec.pod b/pod/perlsec.pod
index 0068d7c..59980d6 100644 (file)
--- a/pod/perlsec.pod
+++ b/pod/perlsec.pod
@@ -420,11 +420,11 @@ code, but none can definitively conceal it (this is true of every
 language, not just Perl).
 
 If you're concerned about people profiting from your code, then the
-bottom line is that nothing but a restrictive licence will give you
+bottom line is that nothing but a restrictive license will give you
 legal security.  License your software and pepper it with threatening
 statements like "This is unpublished proprietary software of XYZ Corp.
 Your access to it does not give you permission to use it blah blah
-blah."  You should see a lawyer to be sure your licence's wording will
+blah."  You should see a lawyer to be sure your license's wording will
 stand up in court.
 
 =head2 Unicode
@@ -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
@@ -493,15 +496,14 @@ Perl running out of memory.
 
 Sorting - the quicksort algorithm used in Perls before 5.8.0 to
 implement the sort() function is very easy to trick into misbehaving
-so that it consumes a lot of time.  Nothing more is required than
-resorting a list already sorted.  Starting from Perl 5.8.0 a different
-sorting algorithm, mergesort, is used.  Mergesort is insensitive to
-its input data, so it cannot be similarly fooled.
+so that it consumes a lot of time.  Starting from Perl 5.8.0 a different
+sorting algorithm, mergesort, is used by default.  Mergesort cannot
+misbehave on any input.
 
 =back
 
 See L<http://www.cs.rice.edu/~scrosby/hash/> for more information,
-and any computer science textbook on the algorithmic complexity.
+and any computer science textbook on algorithmic complexity.
 
 =head1 SEE ALSO