On Mon, Aug 9, 2021 at 5:03 PM Achim Gratz <Stromeko@nexgo.de> wrote: > "Ricardo Signes" writes: > > diff --git a/Encode.pm b/Encode.pm > > index a56a999..9691382 100644 > > --- a/Encode.pm > > +++ b/Encode.pm > > @@ -65,8 +65,8 @@ require Encode::Config; > > eval { > > local $SIG{__DIE__}; > > local $SIG{__WARN__}; > > - local @INC = @INC || (); > > - pop @INC if $INC[-1] eq '.'; > > + local @INC = @INC; > > + pop @INC if @INC && $INC[-1] eq '.'; > > require Encode::ConfigLocal; > > }; > > Hmm, the original change in 3.05 looks… planted; and since Encode.pm is > XS-ed it gets baked in pretty hard. Since that change precludes any > attempt to use Encode::ConfigLocal as intended, this also shows that the > distribution is missing a test for this functionality and that > practically nobody is using it or it should have been caught much > earlier. :-( > > Going back to CVE-2016-1238, why is "." in @INC only removed when it's > at the end (which used to be where it was by default)? Shouldn't it be > sanitized regardless of position, or even more generally any > world-writable components of @INC? > It's quite different to account for the default behavior of Perl up until 5.26, than to account for anyone's modification of @INC which may have a good reason (and if you want to protect against that, you must remove any relative path from @INC, not just '.'). -DanThread Previous | Thread Next