Path: utzoo!attcan!uunet!chinacat!chip
From: chip@chinacat.Unicom.COM (Chip Rosenthal)
Newsgroups: alt.sources.d
Subject: Re: shars and security concerns.
Message-ID: <1203@chinacat.Unicom.COM>
Date: 1 May 90 16:45:17 GMT
References: <662@n4hgf.uucp> <1152@chinacat.Unicom.COM> <518@cpsolv.CPS.COM>
Organization: Unicom Systems Development, Austin (yay!)
Lines: 71

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
some disagreements in areas I feel strongly about.  It's just too much
blood has been spilled trying to get a safe unbundler running, and tired
of every clown who comes up with a wonderful new shar format which adds
nothing but breaks unbundlers.

>Rather than just flame, how about writing a good unshar that does enforce
>reasonable security by interpreting the shar script itself instead of passing
>it off to sh?  There aren't all that many commands to worry about.

Unfortunately, that is not the case.  As you pointed out earlier in the
message:

>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?  For the record, I wish awk weren't in my list.

>Alternatively, perhaps better, how about providing to the world an unshar
>package that sets up the environment that you mention above and runs a
>chroot'ed sh under it?  Now that might be useful!

That's *exactly* what I'm doing.  (If you'd like a copy, I'd be glad to
send one.)  So-called smart shar archives just make things more difficult.
OK, so now some bucko decides he has a better shar maker, it just needs
fgrep and chmod.  What next...tar and cpio?  Fsck?

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.  I never used to be able to
handle these because I'd do "zcat Part01.sh.Z | unshar" and then "zcat
Part02.sh.Z | unshar", and part2 would fail because ark1isdone is no
longer in the unshar tmp directory.  (I eventually gave in and hardwired
recognition of .Z suffixes on the unshar command line.)

Yes, I can (and do) handle every one of these complexities.  However, you
reach a point where it's just easier to have a junk system out back to
do unshar's on rather than providing a utility to do it.

TODAY'S HELPFUL HINT:  If you need to do something special with the setup
or installation of your software distribution (e.g. chmod, uudecode,
etc.), please provide a ten-line sh script in the archive rather than
making it part of the shar archive itself.

>By the way, I am now using shar 3.11 (with my own extensions to do file
>compression) as a handy method for transferring files between my own accounts
>on machines that are connected only by multi-hop UUCP.

That's a neat tool.  But that's not a shar appropriate for distribution.

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.

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?!!??

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

-- 
Chip Rosenthal                            |  You aren't some icon carved out
chip@chinacat.Unicom.COM                  |  of soap, sent down here to clean
Unicom Systems Development, 512-482-8260  |  up my reputation.  -John Hiatt