Front page | perl.perl5.porters |
Postings from July 2016
Now that CVE2016-1238 is public I am bumping this ticket. Documentation can be found at: Initial disclosure: http://code.activestate.com/lists/perl5-porters/231168/ Security RT: https://rt.perl.org/Ticket/Display.html?id=127834 Given these security issues I re-submit the idea that: 1. . be removed from INC by default unless -Dfortify_inc is passed on command line to Configure. I am for there being a Config.pm variable to specify that this was done or chosen. We have much sillier options and hiding this in the bowels just makes it hard for maintainers who intentionally want this behavior to put it back. 2. If the environment variable PERL_USE_UNSAFE_INC=1 is set, then . will be pushed back into @INC as it was in versions of Perl prior to now. This will allow the perl toolchain to maintain its functionality with only minor patches until we can address the toolchain dependance on . in a more reliable way. 3. There were some questions about where I applied patches some of the dual life tool chain modules. I'm open to tweaking those, but I'd honestly prefer these tweaks to happen outside of the original submission. This patch obsoletes the patches we just applied to 5.22 and 5.24. However it will break some small percentage of CPAN modules. I'd like to get this into blead as soon as possible so I can start addressing those issues with CPAN authors as soon as possible so that 5.26.0 goes off as smoothly as possible. So I guess what remains is: Given the nature of CVE-2016-1238, does anyone object in principle to the patches as submitted? Does anyone have any major objections to how I've addressed the toolchain for now. If you do, do you have a workable alternative patch? Thanks, Todd --- via perlbug: queue: perl5 status: open https://rt.perl.org/Ticket/Display.html?id=127810Thread Previous