In perl.git, the branch blead has been updated <http://perl5.git.perl.org/perl.git/commitdiff/7bf591135953a1cdcf4ae91534d66251792771a5?hp=43387ee1abcd83c3c7586b7f7aa86e838d239aac>
- Log ----------------------------------------------------------------- commit 7bf591135953a1cdcf4ae91534d66251792771a5 Author: Yves Orton <[email protected]> Date: Fri Mar 29 12:27:46 2013 +0100 improve hash related documentation in perlfunc and perlsec to reflect new hash randomization logic M pod/perlfunc.pod M pod/perlsec.pod commit fdde5e9b9ea10560698145b51e055fd1c66877eb Author: Yves Orton <[email protected]> Date: Fri Mar 29 12:03:08 2013 +0100 Fix perlfunc.pod to reflect changes to split " " logic M pod/perlfunc.pod ----------------------------------------------------------------------- Summary of changes: pod/perlfunc.pod | 55 +++++++++++++++++++++++++++++++++++------------------ pod/perlsec.pod | 16 +++++++++++++++ 2 files changed, 52 insertions(+), 19 deletions(-) diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod index 7088a9e..050e2d5 100644 --- a/pod/perlfunc.pod +++ b/pod/perlfunc.pod @@ -1650,11 +1650,16 @@ this a syntax error. When called in scalar context, returns only the key (not the value) in a hash, or the index in an array. Hash 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.2 the ordering can be different even between different runs of Perl -for security reasons (see L<perlsec/"Algorithmic Complexity Attacks">). +order is specific to a given hash; the exact same series of operations +on two hashes may result in a different order for each hash. Any insertion +into the hash may change the order, as will any deletion, with the exception +that the most recent key returned by C<each> or C<keys> may be deleted +without changing the order. So long as a given hash is unmodified you may +rely on C<keys>, C<values> and C<each> to repeatedly return the same order +as each other. See L<perlsec/"Algorithmic Complexity Attacks"> for +details on why hash order is randomized. Aside from the guarantees +provided here the exact details of Perl's hash algorithm and the hash +traversal order are subject to change in any release of Perl. After C<each> has returned all entries from the hash or array, the next call to C<each> returns the empty list in list context and C<undef> in @@ -3106,13 +3111,17 @@ named hash, or in Perl 5.12 or later only, the indices of an array. Perl releases prior to 5.12 will produce a syntax error if you try to use an array argument. In scalar context, returns the number of keys or indices. -The keys of a hash 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 can be different even between different runs of -Perl for security reasons (see L<perlsec/"Algorithmic Complexity -Attacks">). +Hash entries are returned in an apparently random order. The actual random +order is specific to a given hash; the exact same series of operations +on two hashes may result in a different order for each hash. Any insertion +into the hash may change the order, as will any deletion, with the exception +that the most recent key returned by C<each> or C<keys> may be deleted +without changing the order. So long as a given hash is unmodified you may +rely on C<keys>, C<values> and C<each> to repeatedly return the same order +as each other. See L<perlsec/"Algorithmic Complexity Attacks"> for +details on why hash order is randomized. Aside from the guarantees +provided here the exact details of Perl's hash algorithm and the hash +traversal order are subject to change in any release of Perl. As a side effect, calling keys() resets the internal iterator of the HASH or ARRAY (see L</each>). In particular, calling keys() in void context resets @@ -6842,7 +6851,10 @@ instead treated as if it were C</\s+/>; in particular, this means that I<any> contiguous whitespace (not just a single space character) is used as a separator. However, this special treatment can be avoided by specifying the pattern S<C</ />> instead of the string S<C<" ">>, thereby allowing -only a single space character to be a separator. +only a single space character to be a separator. In earlier Perl's this +special case was restricted to the use of a plain S<C<" ">> as the +pattern argument to split, in Perl 5.18.0 and later this special case is +triggered by any expression which evaluates as the simple string S<C<" ">>. If omitted, PATTERN defaults to a single space, S<C<" ">>, triggering the previously described I<awk> emulation. @@ -8615,12 +8627,17 @@ hash. In Perl 5.12 or later only, will also return a list of the values of an array; prior to that release, attempting to use an array argument will produce a syntax error. In scalar context, returns the number of values. -When called on a hash, 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">). +Hash entries are returned in an apparently random order. The actual random +order is specific to a given hash; the exact same series of operations +on two hashes may result in a different order for each hash. Any insertion +into the hash may change the order, as will any deletion, with the exception +that the most recent key returned by C<each> or C<keys> may be deleted +without changing the order. So long as a given hash is unmodified you may +rely on C<keys>, C<values> and C<each> to repeatedly return the same order +as each other. See L<perlsec/"Algorithmic Complexity Attacks"> for +details on why hash order is randomized. Aside from the guarantees +provided here the exact details of Perl's hash algorithm and the hash +traversal order are subject to change in any release of Perl. As a side effect, calling values() resets the HASH or ARRAY's internal iterator, see L</each>. (In particular, calling values() in void context diff --git a/pod/perlsec.pod b/pod/perlsec.pod index 7b3f99d..056e8bc 100644 --- a/pod/perlsec.pod +++ b/pod/perlsec.pod @@ -477,6 +477,22 @@ 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). +In Perl 5.18.0 the rehash mechanism has been removed, and replaced by +true randomization similar to that used in 5.8.1. Additionally measures +have been taken to ensure that C<keys>, C<values>, and C<each> return items +in a per-hash randomized order. Modifying a hash by insertion is +guaranteed to change the iteration order. Combined with a hardened +hash function we believe that discovery attacks on the hash seed +are very unlikely. This traversal randomization cannot be disabled, +and is unaffected by the value of PERL_HASH_SEED. + +In addition to these measure as Perl 5.18.0 the source code includes +multiple hash algorithms to choose from. While we believe that the +default perl hash is robust to attack we have included the hash function +Siphash which at the time of release of Perl 5.18.0 is believed to be +of cyptographic strength as a fallback option. This is not the default +as it is much slower than the default hash. + B<Perl has never guaranteed any ordering of the hash keys>, and the ordering has already changed several times during the lifetime of Perl 5. Also, the ordering of hash keys has always been, and -- Perl5 Master Repository
