Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!ginosko!husc6!spdcc!ima!cfisun!lakart!dg
From: dg@lakart.UUCP (David Goodenough)
Newsgroups: comp.sources.d
Subject: Re: Why "shar: Shell Archive  (v1.22)" is bad
Message-ID: <691@lakart.UUCP>
Date: 27 Sep 89 16:29:17 GMT
References: <14502@bloom-beacon.MIT.EDU>
Organization: Lakart Corporation, Newton, MA
Lines: 27

tytso@athena.mit.edu (Theodore Y. Tso) sez:
> Even if some people have /bin/sh, they may not want to use it.  After
> all, shar archives are such a huge potential security hole.  I would
> feel much safer using a parser that didn't allow such constructs as
> "(/bin/rm -rf /) &".  

Agreed. I _NEVER_, repeat _NEVER_, repeat _NEVER_ pass shar files
anywhere near /bin/sh. Instead, I use a heavily hacked version of
Craig Noborg's unshar, written in C. I do this for the maps, and
for any shell archive that arrives in *.sources. By and large it does
the job admirably, even to the point of being able to handle mkdir,
cd (i.e. for multiple directory shars), and split source shell archives.
I take the following approach to Bill D.'s shars: if the output redirection
construct is '>' then just unwrap the file. If it's '>>' and there is no
file already present, then say so, but carry on. That way, you can get bits
out, even if you're missing files. Of course, ugly things will happen if
a huge file is split into three shar files, and you unpack the first and
third w/o doing the second.

However, I'm going to agree with Rich Salz by way of saying that I wish I
hadn't needed to hack it to the degree that I did to be able to handle
some of the stuff that's out there. Remember the KISS principle.
-- 
	dg@lakart.UUCP - David Goodenough		+---+
						IHS	| +-+-+
	....... !harvard!xait!lakart!dg			+-+-+ |
AKA:	dg%lakart.uucp@xait.xerox.com			  +---+