Re: Plan B for fixing 5.8.2 binary API

[Chip Salzenberg <chip@debian.org>]

According to Jan Dubois:
> I think the security implications of hash seeding are totally blown
> out of proportion.

Possible.  But your comments don't persuade me.

> It only helps against one specific DoS attack.

One is enough.

> If security trumps everything else, then I wonder why we[*] don't bother
> to fix the known buffer overrun problems in Perl that result from ignoring
> integer overflow in New(), SvGROW() etc.  Examples for 32 bit machines:
> 
>     perl -e "q(xxxx) x 0x40000000"
>     perl -e "$a[0x40000000] = 1"

I'd never heard of this bug before.  IMO, that's something *else* that
has to get into 5.8.2.

Nevertheless, hash seeding is of high (if not higher) priority because
of the behavior we can reasonably expect from Perl programmers and the
expectations they can reasonably place on Perl.  Using an unchecked
input string as a hash key has *always* been safe in ways that using
an unchecked number as an array index clearly is not.  After all, no
matter what string you get, it's only *one* hash key; nothing will
blow up if you use it.  If you use a big number as an array index,
*kaboom*.  (Even if the overflow bug is fixed, you'll still get an
out-of-memory exception.)

In short, what makes the hash seeding so important is not the nature
of the hashing DOS, but the prevailing and justifiable expectation of
hash key safety.
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K