Propagating environment to taint tests
Michael G Schwern
schwern at pobox.com
Mon Oct 1 00:41:33 BST 2007
Eric Wilhelm wrote:
>> This behavior is pushed down into TAP::Parser, it's not just a
>> Test::Harness compatibility thing. I feel it is of a different
>> nature then of propagating the harness' @INC down to the tests
>> because otherwise the taint tests would be unlikely to run. Consider
>> someone who has installed modules via fink. fink puts /sw/lib/perl5
>> into PERL5LIB.
>
> Note though that we're making tests run under taint when actual code in
> that environment wouldn't find the module (or (eek!) would find a
> different one.)
Yep, that's the idea.
> Was this by any chance a workaround for something MakeMaker was doing?
> (I notice that the Makefile's PERL5LIB contains "lib".)
Nope, it's to allow the author to put -T on the #! line of their tests without
having to worry about how the user's @INC is constructed. Purely a
Test::Harness convenience feature to make shipping taint tests viable.
MakeMaker's PERL5LIB contains 'lib' so that it builds itself with itself at
all points of the build process, that came much later.
> I can support the DWIM as far as making taint tests work, but we should
> probably think about making it switchable (i.e. the ability to disable
> the DWIM and maybe warn when a PERL5LIB-resident module gets loaded
> under taint (though the latter my be difficult to determine without
> attaching instrumentation to e.g. the test's CORE::GLOBAL::require().))
We can certainly have a flag to turn off the special support for tainted modules.
That warning idea is more something that an author can write up in their own
test, we don't need to provide support for that.
--
Stabbing you in the face for your own good.
More information about the tapx-dev
mailing list