shars and security concerns.

[Tom Neff]

In article <FQ53S_xds13 at ficc.uu.net> peter at ficc.uu.net (Peter da Silva) writes:
>I still fail to understand the security concerns of shars, apart from the
>single case of comp.mail.maps.

It's not *just* security, although that's part of it.  It's also
reliability, portability and overall safety (not just protection against
malice).  Shell archives should not do strange crap.  They should do the
absolute minimum necessary to create a fileset on minimally POSIX-ish
systems, while LOOKING uniform in structure so that non-Bourne extractor
programs can understand them.

I would allow only six basic operations: create file, create directory,
mark executable, verify integrity, echo to user and abort.  Additional
information, like file modes, times etc, can be placed into special
header lines which are just comments to the shell:

#%# Name=sample.1 Mode=0644 Uid=101 Gid=5 Size=2194 Mtime=04617601375 
#%# Chksum=011240 Typeflag=0 Uname=tneff Gname=other

in a standardized format where a *smart* unshar utility (which should
itself be promulgated widely) can recognize it and do more precise
extraction as and if the user wants it.

Someone asked whether there should be an RFC for shell archives.  I think
there should.  It should then be subsumed into P1003.whoever.  The above
header format fits in fairly well with the direction they seem to be moving,
although someone can probably clean it up.

This other trend, where people create shell archives that try to rewind
your magtape and put the cat out, is bogus.

-- 
"We walked on the moon --       ((      Tom Neff
     you be polite"              ))     tneff at bfmny0.UU.NET