in reply to Mitigating ". in @INC" for optional dependencies

no lib q{.}; # mitigate the ". in @INC" security threat vector # when using optional dependencies

Well,if you talk security, you should use -T anyways. See perlrun and perlsec for "Taint mode", which implies "." not being included in @INC.

As a (weaker) alternative, you could localize @INC in your eval block:

@ARGV = Win32::CommandLine::argv() if eval { local @INC = grep !/^\.$/, @INC; # LHS is localized, RHS gets glob +al @INC require Win32::CommandLine; };

This localized restriction then applies to all modules loaded by Win32::CommandLine as well, but not to subsequent code in your script-foo.pl.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Replies are listed 'Best First'.
Re^2: Mitigating ". in @INC" for optional dependencies
by Wyrdweaver (Beadle) on Sep 10, 2016 at 20:54 UTC

    I like it.

    Are there any caveats for using the same idiom within modules...

    use Term::ANSIColor; () = eval { local @INC = grep !/^\.$/, @INC; require Win32::Console::A +NSI } if 'MSWin32' eq $^O;
    ?

    I'm advocating this idiom to any/all module authors using color in order to improve portability, and I don't want to impact their state negatively.

    Hopefully, 'Term::Color' will adopt it into it's synopsis text to further the cause.

      Are there any caveats for using the same idiom within modules...

      I can't see any caveats for using it within modules. It is the modules author's choice to permit or restrict the (arguably unsafe) "." in @INC. I'd consider modules relying on "." inside @INC to be broken. They shouldn't rely on "." but use something else to get their location, e.g. FindBin or __FILE__ or such - if they are not explicitly chameleonic modules.

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'