develooper Front page | perl.perl5.porters | Postings from October 2012

Re: Security Issues in perl-5.16.x

Thread Previous | Thread Next
October 1, 2012 21:28
Re: Security Issues in perl-5.16.x
Message ID:
On 2 October 2012 05:49, Aristotle Pagaltzis <> wrote:
> * demerphq <> [2012-10-02 04:05]:
>> Perl never promised to save anyone from shooting their foot off, quite
>> the opposite. That is very different from someone diligent being
>> vulnerable because they use Perl due to a bug in Perl.
>> So far you haven't shown the latter and this conversation sounds like
>> FUD motivated by the p5p community not doing what you want us to do.
> So far I don’t see any security implications either. This seems like
> a case of Reini doing himself a disservice. Needlessly alarming rhetoric
> or not, see, I agree with him that syscalls shouldn’t be passed NULs.
> Sure, Perl enough rope to shoot yourself yada yada; but that applies to
> where Perl doesn’t keep you from doing stupid things because doing so
> would also keep you from doing clever things. In this case, which *are*
> the clever things you could be doing? Can you illustrate how this aspect
> of perl’s behaviour can be used fruitfully? Or is it just a (mostly
> harmless?) oddity that won’t get fixed simply because, well, it’s stupid
> and you’re allowed to do stupid things?
> [Note I’m not (at this time) arguing about what action should be taken.
>  What I’m asking is only whether we agree on the principle.]

Changing how we handle nulls in some of these cases seems reasonable to me.

I don't think anybody would object to a sensible discussion about
this, but the hyperbole and accusations of bad faith are not


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About