On Thu, Dec 30, 2004 at 11:29:17AM -0500, [EMAIL PROTECTED] wrote: > > SECURITY CONSIDERATIONS > > 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 indexes. 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 documentation. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ If you can't remember, the Claymore is pointed at you.
