Front page | perl.perl5.porters |
Postings from December 2004
Michael G Schwern <schwern@pobox.com> wrote on 12/29/2004 10:33:02 PM:
> Its also hideously insecure. You're running a shell script that could do
> anything. A problem with any self-extracting archive.
>
> From shar(1).
>
> 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. It is interesting to note also that
these days many folks login to linux as root 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.
> > While I doubt that:
> >
> > make shdist
> >
> > or:
> >
> > mmk shdist
> >
> > is often used nowadays to prepare somehting for upload to CPAN, I
suspect
> > that
> > removing it might adversely affect folks that have to email perl module
> > distributions along 7 bit email relays
>
> For those that need that there is uutardist. Or if they really need it
> they can just uuencode or base64 encode the tarball themselves. Or let
> their MTA do it as is the current practice.
The emailability of Unix shar or VMS share files is one consideration.
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. (Hmm, perhaps we need a new pcsidist
target?
Then there is that whole ppm thing that was supposed to be the be all of
binary dist formats especially suited to folks that had no compiler... so
many dist formats to choose from.)
> I'd throw shdist out if I didn't think it would be more trouble than its
> worth. I hope nobody's using it.
I think the unportability of shar was its main downfall rather than
security concerns. The shar file might be able to unpack with:
sh sharfile
on SunOS 4.3 but it might not unpack on HP-UX 11.x (most likely since some
necessary utility was not on your $PATH). It's not that bad to support,
and it is not too popular, some folks might want to have it for some reason
that I may or may not have been able to put forth.
Peter Prymmer