Beyond shar (Re: shars and security concerns.)

[Tom Neff]

In article <--830L1ggpc2 at ficc.uu.net> peter at ficc.uu.net (Peter da Silva) writes:
>Sure, we can unpack shars with unshar programs, but as shars get more and
>more out of hand it gets more and more of a pain to keep mangling things.

With proper standardization it should not be necessary for an unshar
program to handle all kinds of weird shars.  If a portable shar/unshar
pair were promulgated that incorporates detailed file information for
unshar itself, and minimal self-extraction capability for UNIX-like
environments without the unshar program, that should be enough.

>Why not just switch to something that was (once upon a time, anyway) common,
>real simple, and documented in any competant programmer's library (anyone who
>doesn't have "Software Tools" needs to get it, IMHO). The Software Tools
>archive format.

Because it doesn't self extract.  I hate to sound obvious, but if the
Software Tools format were intrinsically superior in practice we'd
probably already be using it.  (Although not to package our news article
text, hehe)

Also, my memory may be faulty but the last time I looked at ST it seemed
to me there was no provision for recording modes or ownership.  Peter may
correct me on this.

I would repeat my suggestion, which is to adopt a minimal shar that has
header comments of the form

	#%# Name=.article Mode=0644 Mtime=641968578 Owner=tneff
	#%# Checksum=1943729 Type=text

and issue shar/unshar programs that generate and decode them.  The user
can ignore some or all header info with option switches to unshar.