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 +---+