On Tue, Feb 06, 2001 at 12:49:28AM +0100, Bart Lateur wrote:
> On Mon, 05 Feb 2001 11:35:59 -0500, Dan Sugalski wrote:
>
> >> > use autoload { Bar => 'http://www.cpan.org/modules/Bar' },
> >> > { Baz => 'ftp://my.local.domain/perl-modules/Baz', VERSION =>
> >>2 };
> >>
> >>Very good idea indeed!!! Append the wishlist to add this module to perl6's
> >>standard library!!!
> >
> >Very *bad* idea. It sounds nice, but using a remote module without any sort
> >of control is just begging for trouble.
and even if the script contains the MD5s or some other key for the modules
it trusts, what stops me cracking the ftp server, and modifying the script
so that it has the MD5s of my new "improved" versions.
Why write your worm in vbscript when perl gives you language features to
let you do it as a 1 liner?
[as currently doing something like opening a socket, and feeding that on
stdin to a child perl to read as a script will take more lines and be
more obvious what you're up to. Probably. Old example on request]
> I agree. Plus, it strikes me as asking for trouble. It sounds make-ish.
> So every time you run a script, it could actually *upgrade* your module
> behind your back, without you checking it!
Quite. It's brilliant. I don't even need to crack your script to get past
your firewall. I steal someone else's signing key, sign a new version of
a legitimate module you're already using, and make that module use autoload
whatever I wanted to run. World domination is mine...
> But, this discussion gives me yet another idea. Think of a module,
> somewhat like the B::* modules. This one could check your script, and
> prevent perl from running it, but instead try to install any modules
> that you're missing. The installation itself of the modules could be
> handled by (an extension of) CPAN.pm. Of course, it shouldn't upgrade,
> i.e. replace, any previously installed modules without your explicit
> consent.
I think it would have to run some of the remotely loaded untrusted module
as it would need to execute all the script's BEGIN code, hence everything
in the module that runs during use, as http://www.cpan.org/modules/Bar
might in turn require more modules.
But hopefully this is in a safe compartment, with untrusted modules run
from the build tree by pushing @INC each time, and presumably
optionally interactive:
Module Bar wants Foo version 1.3 or greater.
Should I download this from http://www.cpan.org/modules/Foo and build it
[Y/n]?
On the other hand you could avoid running the untrusted module by
iteratively repeating the process. Go 1 finds you have Bar missing, so you
stop, download, build, test, check that you trust it, install it
Restart, go 2 finds that Bar would like Foo
[although modules ought to be good and get their dependencies right in
Makefile.PL]
and so on. But this has the disadvantage that you don't know how much
you're letting yourself in for (in terms of new modules) until you've
already started committing them to your installed tree.
Nicholas Clark
