Front page | perl.perl5.porters |
Postings from March 2012
Re: pop @INC (".")
From: Todd Rinaldo
March 12, 2012 05:11
Re: pop @INC (".")
Message ID: 1522CF5B-6A71-4EBA-8366-E561DB4E611C@cpanel.net
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
> 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.
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. Hopefully they're reading the change log when they upgrade their perl 3 code to perl 5.18.