Re: Plan B for fixing 5.8.2 binary API
On Mon, 13 Oct 2003 14:57:59 -0400, Chip Salzenberg <email@example.com>
>IMO, high-quality hash seeding is more important than XS binary
>compatibility. Seeding is a security feature, and security trumps
>just about anything else[*]. If we can't make any plan for seeding
>*with* bincompat work right -- though I'm confident that we can --
>then we should break the binary API in a way that requires
>recompilation of XSs that use PERL_HASH(). Weak hash seeding is
>simply Not OK. IMO.
I think the security implications of hash seeding are totally blown out of
proportion. It only helps against one specific DoS attack. This
vulnerability still doesn't provide the attacker with access to the box
itself. And there are plenty of DDoS attacks that hash seeding won't help
against at all.
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"
This has been sitting in the bug database for years and might be a real
security risk for applications not doing proper argument checking.
As for hash seeding, binary compatibility for the maintenance track is
more important *for the ActivePerl distribution* from my point of view. I
understand that for other environments binary compatibility might be less
of an issue. That's why it is cool that it is build time configurable. :)
[*] If nobody beats me to it, I'll look into the buffer size overflow
problems sometime next month. I think this really should be fixed for