Tracker: This tracker is to keep track of Perl based packages that need fixing for the 5.26 removal of "." from @INC, and will thus block 5.26 stabilization ( once it becomes a candidate for such ) Tracker will just start out being comments of affected packages for later work (after 5.26 actually enters tree), and eventually this tracker will be blocked by stabilization requests for necessary modules. Context: Prior to Perl 5.26, the Perl Module Load path was: - /etc/ - /usr/local/${libdir}/perl5/${perlversion} - /usr/${libdir}/perl5/vendor_perl/${perl_version} - /usr/${libdir}/perl5/${perl_version} - . The last of which being an implied "look in $CWD" mechanic as a fallback if the other paths failed. Due to a class of security holes where certain code could rely on a given module being missing ( eg: eval { require Module } || fallback or simply unchecked "do $file" ), a malicious user could place vulnerable files in locations where they could anticipate a privileged user being when they execute a known vulnerable program. 5.26 closes this specific class of issue by removing the "fallback to CWD" mechanism, however, as a consequence affects a lot of code that was relying on that mechanism, where it wasn't an implicit security risk. These typically are most visible in: - Class 1. Perl Module Installers ( eg: Makefile.PL / Build.PL execution ) - Class 2. Perl Module Tests ( eg: t/* ) where expressions like use inc::Module::Install ; # ./inc/Module/Install.pm use t::Foo ; # ./t/Foo.pm or do "t/Foo.pm" ; # ./t/Foo.pm Relied on this resolution for good effect, due to the assumable and safe stance that Installers and Tests are executed from an enforced CWD. There is also plenty of code in the wild: Class 3 (esp. outside CPAN) that relies on CWD-relative loading for configuration parsing purposes, similar to how running "git" doesn't need any explicit path passing to work ( because CWD is assumable ) However, all of the above usecases break in 5.26 when 5.26 is compiled with -Ddefault_inc_excludes_dot ( The intended default ), and traditional behaviour can only be restored at a global level via passing -Udefault_inc_excludes_dot to Perl's ./configure Upstream are providing mitigations in some places for the "Installers" and "Tests" contexts, but the expected long-term plan is that these mitigations will eventually go away. Upstream mitigations are employed by: 1. Setting PERL_USE_UNSAFE_INC=1 in CPAN clients if the ENV var is not already set. 2. Adding PERL_USE_UNSAFE_INC=1 in Test::Harness and `prove` if the ENV var is not set. These strategies suppress all classes of errors, but only during install and test phases. These are (mostly) satisfactory short term mitigations for classes 1 and 2, because they don't ever "live" outside that context. However, they suppress real problems in class 3: Installed time. Subsequently, we have no plans as such to suppress these classes of error in Portage, rather, to expose them and let them fail at the testers level and get them Fixed Properly, and then block 5.26 stabilization on the fixes themselves being stabilized. End Users who have problems with this can simply set-and-forget PERL_USE_UNSAFE_INC=1 in a place or two, and these problems will go away ( at the price of security ). News notifications will be sent closer to the time where they need to care.
<dev-perl/Devel-Symdump-2.180.0
99% of this is fixed, no real point to keep the tracker open.
