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

Re: Security Issues in perl-5.16.x

Thread Previous | Thread Next
From:
Jesse Luehrs
Date:
October 2, 2012 17:12
Subject:
Re: Security Issues in perl-5.16.x
Message ID:
20121003001226.GH10026@tozt.net
On Tue, Oct 02, 2012 at 07:44:46PM -0400, David Golden wrote:
> On Tue, Oct 2, 2012 at 7:40 PM, Chip Salzenberg <rev.chip@gmail.com> wrote:
> > On Tue, Oct 2, 2012 at 4:32 PM, Jesse Luehrs <doy@tozt.net> wrote:
> >> The point that Chip is making is: how would you propose stopping package
> >> names from containing nulls?
> >
> > Indeed.  And with a large side order of why.
> 
> However, if we had originally disallowed them, how would we react to a
> proposal to allow them?  I suspect the answer is "with great
> skepticism".
> 
> Historical accident is a weak justification for a particular design.
> The response "changing it now is too much work/too risky" could be a
> fair justification for status quo, but I haven't heard that
> convincingly yet.

I feel like we're talking about two different things here. "Package
names" don't have any mapping to file names except via require (and only
the require EXPR form of that, since nuls aren't allowed by the parser
for require BAREWORD). Whether the open() call that require makes dies
when it gets a nul in its input string is a separate issue from whether
'$::{"foo\0bar"} = ...' or '$INC{"foo\0bar"} = ...' should die. I feel
like system calls that end up with a nul in their input should die (or
at least warn), but I don't see how '$::{"foo\0bar"} = 1' should be any
different from '$foo{"foo\0bar"} = 1'.

-doy

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About