develooper Front page | perl.module-authors | Postings from November 2005

Re: When CPAN shell cannot find a module

Thread Previous | Thread Next
From:
Christopher Hicks
Date:
November 21, 2005 10:57
Subject:
Re: When CPAN shell cannot find a module
Message ID:
Pine.LNX.4.63.0511211346270.12572@skippy.fini.net
On Mon, 21 Nov 2005, Chris Dolan wrote:
> If CPAN made it easy to install unintended software by mistake, that 
> would be a huge security hole.  Some people run cpan as root. 
> Defensive programming is absolutely the right thing here.

And how exactly would a shortcut that says "oh you asked for something 
that isn't really a module name, would you like us to install THIS package 
which contains CERTAIN modules anyway?" cause security issues?  I run the 
cpan shell as root all the time.  Its a pain to have to remember the CPAN 
caniptions every time I'm setting up a new random server and the less 
often you deal with it the more likely you will have forgotten it all. 
This is exactly the context where the sort of shortcut that Perl is known 
for should be eximplified but its not.  It may be the individual's first 
exposure to the Perl world.  Let's not make it suck because of weak fears.

PathTools and Template Toolkit are both examples where the thing to type 
into CPAN isn't clear to the newbie sysadmins.  If we had a list of things 
like that for the important modules that have such strangeness then 
there should be any security problem in doing this without prompting since 
those mappings would be official and Known To Be OK.  If I say
 	install TemplateToolkit
or
 	install Template::Toolkit
having that map to
 	install Template
without too much fuss is not only harmless and significantly helpful it 
might even be a security benefit since I won't accidentally install three 
other templating things in the meantime hoping to find the right one.  The 
amount of time saved for sysadmins all over the world without causing 
anyone one iota of actual harm is awe-inspiring.

So, am I really missing something here?  Is there really some chance for a 
harmful mistake being made that can't be trivially mitigated with 
solutions like I mentioned above?

-- 
</chris>

There are two ways of constructing a software design. One way is to make 
it so simple that there are obviously no deficiencies. And the other way 
is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About