Front page | perl.perl5.porters |
Postings from March 2012
Re: pop @INC (".")
March 12, 2012 06:00
Re: pop @INC (".")
Message ID: 20120312130034.GG30900@almanda
On Mon, Mar 12, 2012 at 07:11:47AM -0500, Todd Rinaldo wrote:
> On Mar 11, 2012, at 11:19 AM, Abigail wrote:
> > On Fri, Mar 09, 2012 at 06:44:18PM +0200, Niko Tyni wrote:
> >> On Fri, Mar 09, 2012 at 06:18:59AM -0700, Tom Christiansen wrote:
> >> We've been here before, see the thread at
> >> http://www.nntp.perl.org/group/perl.perl5.porters/2010/08/msg162729.html
> > But if you run such programs in an untrusted environment, shouldn't you
> > (at least) run with -T? Or, simply, change cwd() to something "secure"
> > before running? Or put a "no lib '.';" on top of the program? Or use
> > -M-lib=. on the command line? Or to add "-M-lib=." to PERL5LIB? Given that
> > all these measures already exists right now, what's the added value of
> > having yet another way?
> I think this sort of gets into philosophy. The discussion is about
> whether or not you want to build with "security by default" or if you
> expect every person using perl in a "privileged" way to know they need
> to do one or all of the above. If anything, I'm surprised that someone
> from Debian took so long to pipe in on this topic. I don't speak for the
> Debian perl folks, but I wouldn't be surprised if they opted to build
> their perl with this feature if it was given upstream support.
> Not to draw too close a parallel, but it's my understanding that
> the Github breach came down to code which expected you to lock it down
> if you used it in a secure way. Even a full time staff running these
> servers overlooked a place where they should have in perl terms done
> "no lib qw/./" but neglected to.
> If one were to take my proposal to a logical extreme, the suggestion
> might be that we also allow people to build perl with taint mode on by
> default and require it to be explicitly disabled. I do feel this would
> break a significant amount of code, so I'm trying to strike a balance
> by proposing the option to remove "." from @INC.
I've no problem with a build option to remove "." from @INC. I do not believe
it's in our interest to change the default behaviour.
> My thinking is that removing "." from @INC will in fact break CPAN
> stuff. However, at least since 5.12, changes have been in every major
> perl release that required CPAN modules to make minor changes in order
> to keep up with the L&G perl. With respect to dark pan code, I'm with
> whoever said it before: Someone has to actively choose to upgrade perl
> before it affects their darkpan code.
Just because we someone times make a careful decision to break backwards
compatability, we shouldn't treat that as a reason to do so willy-nilly.
We *want* people to upgrade their Perl, and we want that process to be
as smooth as possible. Any breakage in backwards compatability makes that
process harder; and should be carefully considered. Removing "." from @INC
by default doesn't make that cut, IMO. The benefit are little (it's only
useful in a restricted set of cases, comes automatically if you do whatever
you ought to be doing when running in an untrusted enviroment (-T), and
there are several easy ways to already achieve the effect), but it does
have the potential to break lots of code.
> Hopefully they're reading the
> change log when they upgrade their perl 3 code to perl 5.18.
I really do not like that sentiment. Do realize that almost all packages
on CPAN by themselves are worthless. They're just modules, and most of
them do not contain complete program or applications. It's "darkpan"
code that enables their usefulness.