Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bfmny0!tneff From: tneff@bfmny0.UU.NET (Tom Neff) Newsgroups: alt.sources.d Subject: Re: shars and security concerns. Message-ID: <15441@bfmny0.UU.NET> Date: 2 May 90 06:46:17 GMT References: <662@n4hgf.uucp> <1152@chinacat.Unicom.COM> <518@cpsolv.CPS.COM> <1203@chinacat.Unicom.COM> Reply-To: tneff@bfmny0.UU.NET (Tom Neff) Lines: 34 In article peter@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@bfmny0.UU.NET