Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!samsung!emory!kd4nc!n4hgf!wht
From: wht@n4hgf.uucp (Warren Tucker)
Newsgroups: alt.sources.d
Subject: Re: shars and security concerns.
Message-ID: <680@n4hgf.uucp>
Date: 2 May 90 16:03:46 GMT
References: <662@n4hgf.uucp> <1152@chinacat.Unicom.COM> <518@cpsolv.CPS.COM> <1203@chinacat.Unicom.COM>
Reply-To: wht@n4hgf.UUCP (Warren Tucker)
Organization: Amateur Radio Station N4HGF
Lines: 51

In article <1203@chinacat.Unicom.COM> chip@chinacat.Unicom.COM (Chip Rosenthal) writes:
>In article <518@cpsolv.CPS.COM> rhg@cpsolv.uucp (Richard H. Gumpertz) writes:
>> [ in response to my flame that smart shar's are evil and rude ]
>
>While my original message was certainly a flame, this isn't.  I do have

I said I wasn't gonna say anything else on this topic.  But, alas, ...

>By far the *worst* of the smart shar archives are those which try to be
>cute and split files across multi-part archives so that they are all the
>same length.  This is just anal to the max. 

Anal?  Anal?  Most of the anal types I know would have it squirting out
all over if they thought one of their files had been split up by a
program.  It is merely a side effect that the shar sizes are similar;
the purpose is to limit the size to accommodate mail systems or other
transport mechanisms.  Somebody in the history of this evil neo-pseudo-shar
thought it a disk-consuming limitation that you had to have disk
temporarily available for the entire shar set, the file parts it unwraps
AND the target reconstructed files.  I agree with him.

>>You provide awk and sed but refuse to provide fgrep?  How is the latter any
>>more dangerous?
>
>It isn't any more dangerous.  The question is do I have to provide an
>entire filesystem of bin utilities just in order to let a lousy shar
>package unbundle itself?

Why not?  I do.  As a matter of fact, the programs in /bin have been
tested to the satisfaction of most.  The shell scripts unwrapped by the
shar are _probably_ going to have access to /bin ;->.

>Look, the purpose of a shar archive is really simple - to provide a bunch
>of files in a self-extracting format.  Most of the whizzy features people
>throw into their shar archive do nothing to enhance this base purpose.
>They are just crap...err...unrequired features.

To you, then, perhaps a shell should check a program name against
an approved list of programs and execute it, passing arguments as is.
Other features are unnecessary.

>Now, this isn't an absolute.  The shar's I make aren't just "cat<<'EOF'".
>I do use sed, wc, and test (and mkdir if required).  But that's it.  I also
>justified to myself the added complexity of each "improvement".  I wish
>more folks would.  Keep it simple.  Please?!!??

Oh, ok, you do recognize the need for ...err... features.  Please allow
others to justify to themselves the need for "additional complexity".
All of the features I've seen in any shar producer are really quite simple.

>Not rhetorical: would shar format be an appropriate topic for an RFC?

Now, _that_ is anal.

If you are worried by the commands I use to deliver source to you, you
will probably be terrified of the fact that system calls are in that
source.  My advice is to let us keep our shars and if your amniotic
membrane won't let the source inside, just rm and forget it. You don't
need the trauma.  Jeez, at least shell and editor wars had some religious
validity. But shar wars?
 
------------------------------------------------------------------
Warren Tucker, TuckerWare gatech!n4hgf!wht or wht%n4hgf@gatech.edu
McCarthyism did to cinema what ANSI did to C,  cast a great number
of characters into the void.