develooper Front page | perl.perl5.porters | Postings from December 2004

Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06

Thread Previous | Thread Next
Michael G Schwern
December 30, 2004 12:10
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Message ID:
On Thu, Dec 30, 2004 at 11:29:17AM -0500, wrote:
> >      It is easy to insert trojan horses into shar files.  It is strongly
> rec-
> >      ommended that all shell archive files be examined before running
> them
> >      through sh(1).  Archives produced using this implementation of shar
> may
> >      be easily examined with the command:
> >
> >            egrep -v '^[X#]' shar.file
> I find it interesting to note too that the command:
>     perl Makefile.PL
> can be made to do anything provided a trojan horse has been inserted
> either directly into the Makefile.PL file or into another file that
> Makefile.PL either requires or do()'s.

To make a long story short, CPAN has a built in layer of trust that receiving
a self-extracting archive via email does not.  In that in order for a
significant number of people to download and run your Makefile.PL you will 
have had to have written a module that is actually useful and wanted.  And
the number of malicious pranksters who are willing to put in the effort to 
do this has so far been 0.  CPAN also has built-in anti-namespace-hijacking
so I can't upload a trojan DBI-99.99.tar.gz and have it appear in the 

Also, by installing the code you're trusting their module doesn't do 
something nasty so its fair to say that you can trust their Makefile.PL, too.

Also, there is no safe alternative to Makefile.PL.  At some point you're 
going to execute their code.  But there are plenty of safe alternatives to 
self-extracting archives.

Finally, it does not excuse X to be insecure because Y is, too.

> It is interesting to note also that these days many folks login to linux 
> as root

I cannot accout for every stupid thing users do.  I can only make it a little
less likely they'll blow off their own foot or other's.

> and they may not even
> directly run that command after having examined the Makefile.PL since they
> may be using a convenience utility such as the CPAN shell.

CPANPLUS now supports 'sudo' so that it is no longer necessary to run the
CPAN shell as root.  Everything but "make install" can be run as a normal
user.  However, a trojan Makefile.PL can always inject malicious code into
the install target so its not much help.  See my earlier comment about
built in trust.

> Another is that the native VMS command @ is all that is needed to unpack a
> VMS_SHARE prepared file.  In fact, the (VMS_)share format is as close to a
> native VMS compatible dist format as MakeMaker currently offers.  All of
> the others: *.zip, *.tar.gz, *.tar.bz2, etc. require the installation of a
> special non VMS native unpacking program.

I'm thinking that if you're on a system that can't handle tar.gz or zip
files installing Perl modules is the least of your worries.  This is an
edge case that might have been an issue 10 years ago (shdist was introduced
in MakeMaker 4.1 May 1995) but I really doubt it now as its so trivial to
get unzip onto a VMS machine even I can do it.

In the extraordinarily unlikely case that someone has a stock VMS system and
they cannot, for some reason, install unzip or tar they can always go to
a sensible machine, unpack a tgz distribution and shar it themselves.

That said, I don't plan on removing shdist unless it starts causing
trouble.  I may, however, deprecate it and/or remove it from the 

Michael G Schwern
If you can't remember, the Claymore is pointed at you.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About