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

RE: Security Issues in perl-5.16.x

Thread Previous | Thread Next
bulk 88
October 5, 2012 22:37
RE: Security Issues in perl-5.16.x
Message ID:

> Date: Thu, 4 Oct 2012 04:48:09 +0200
> From:
> To:
> Subject: Re: Security Issues in perl-5.16.x
> * Reverend Chip <> [2012-10-03 21:45]:
> > On 10/3/2012 1:44 AM, Aristotle Pagaltzis wrote:
> > > So far I have seen no justification for the behaviour other than
> > > “it does not cause any harm”.
> >
> > Funny! And yet:
> >
> > > Can we be serious for a moment here?
> >
> > Sure. Serious. This is my serious face.
> >
> > /p5p has become a slow-moving parody of itself
> Well, at least you are entertained. Then all this wasn’t worthless
> on *every* count.

I am not entertained. I'm not particularly interested in this topic. Maybe this debate can be solved with a wiki page that describes each so called problem, then a list of proposed resolutions, each with a pro and con section.

I think the question is, is the user responsible for sanitizing I/O to disk, or is it Perl responsible? And what about OSes that are fine with a null or any byte in the filename (Im not sure which these are)? And are hash keys and/or package names supposed to be only of printable characters or not?

From reading here and on #p5p, why is storing shellcode in a module name given to require so much more dangerous than storing it in a scalar? Or are there Perl GUI editors where the watch windows are vulnerable to null truncation hiding the exploit payload right infront of the eyes of the developer who is step debugging it?
Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About