Re: Checking module (of a level) being installed

Replies are listed 'Best First'.
Re^2: Checking module (of a level) being installed by Tanktalus (Canon) on Apr 11, 2005 at 16:43 UTC
Thanks. I would like to point out that we have a slightly different take on things, which Perl is making more and more difficult ;-) On one hand, as you point out, that I completely forgot about, is that modules can load and do nasty things. Ones that do nasty things on require should be taken out behind the barn and shot. On use (aka, import) is another matter. And even then, nasty things such as those Acme modules aren't likely to make it into my corporate build tree :-) On the other hand, putting CODE refs into @INC is now perfectly plausible - I doubt any solution other than physically loading the module (somehow) will work. Placing your whole VM at risk of infection by whatever is being loaded... having a "use Blather;" line results in Acme::emcA would be problematic in many ways, not the least of which would be manifested at runtime. So, we'll assume, for the minute, that CODE refs in @INC are simply ways to load things in a funny way, and not ways to barrel over the existing code tree. At the bottom of it all is the fact that I'm not actually using CODE refs in @INC, nor using anything from Acme::*, so I'm going to take a closer look at ExtUtils::MM->version(). I'm not looking for the versions of every single module in the system - just a few. So the idea is to find those modules in @INC and see if ExtUtils::MM can figure out just those specific versions. Thanks!	[reply]

Replies are listed 'Best First'.

Re^2: Checking module (of a level) being installed
by Tanktalus (Canon) on Apr 11, 2005 at 16:43 UTC

Thanks. I would like to point out that we have a slightly different take on things, which Perl is making more and more difficult ;-)

On one hand, as you point out, that I completely forgot about, is that modules can load and do nasty things. Ones that do nasty things on require should be taken out behind the barn and shot. On use (aka, import) is another matter. And even then, nasty things such as those Acme modules aren't likely to make it into my corporate build tree :-)

On the other hand, putting CODE refs into @INC is now perfectly plausible - I doubt any solution other than physically loading the module (somehow) will work. Placing your whole VM at risk of infection by whatever is being loaded... having a "use Blather;" line results in Acme::emcA would be problematic in many ways, not the least of which would be manifested at runtime. So, we'll assume, for the minute, that CODE refs in @INC are simply ways to load things in a funny way, and not ways to barrel over the existing code tree.

At the bottom of it all is the fact that I'm not actually using CODE refs in @INC, nor using anything from Acme::*, so I'm going to take a closer look at ExtUtils::MM->version(). I'm not looking for the versions of every single module in the system - just a few. So the idea is to find those modules in @INC and see if ExtUtils::MM can figure out just those specific versions. Thanks!

[reply]