Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!uoft02!grx1042 From: grx1042@uoft02.utoledo.edu (Steve Snodgrass) Newsgroups: comp.sys.amiga Subject: Re: Self Extracting Archives Message-ID: <123.2603966e@uoft02.utoledo.edu> Date: 18 Mar 90 19:08:46 GMT References: <55.25f441b5@uoft02.utoledo.edu> <195@sai.UUCP> <2675@leah.Albany.Edu> <79.25f87ef0@uoft02.utoledo.edu> <10102@cbmvax.commodore.com> <90.25fc5fd6@uoft02.utoledo.edu> <492d7755.1a5bf@moth.engin.umich.edu> <104.25fdcdd4@uoft02.utoledo.edu> <270@ Lines: 64 estinc.uucp> Followup-To: stinc.uucp> Distribution: na Organization: SUBTEC Lines: 57 In article <270@estinc.UUCP>, fnf@estinc.UUCP (Fred Fish) writes: > In article <104.25fdcdd4@uoft02.utoledo.edu> grx1042@uoft02.utoledo.edu (Steve Snodgrass) writes: >>Anyone who goes to *THAT* much trouble could just as easily create an >>executable file that looked completely innocuous and put it in a zoo archive. >>The point here is that any argument applied against a self-extracting archive >>can also be applied against an executable inside a zoo file. > > I would have stayed out of this discussion except for the fact that I find > SXA's particularly distasteful. Anyway, the above statement is clearly false > because there exists a set of arguments against SXA's that cannot be applied > against executables inside a normal archive for the simple reason that they > are not applicable. For example: Fred, First, I want to say this will be my last posting on the topic. I think this has gotten to the point where we are wasting bandwith. The main point lots of people are missing here is that the only real reason for having SXA's around is for archiving programs, i.e. so the new user can download something without having an archiver first. I DO agree that, otherwise, you shouldn't be using an SXA. > 1. There is no simple way to get a listing of the contents > of an SXA. There is a simple way for non-SXA's. Yes there is, at least for PAK, the only one available on the Amiga. Just use PAK. Of course, someone previously pointed out that this sort of makes the SXA idea pointless, since it requires you to have the archiving program. > 2. The extraction code for an SXA may do bad things to your > system. There is no extraction code inside a non-SXA, it > is in the "trusted" archive program instead. This is what I'm talking about when I say: "Any argument that can be applied to an SXA can be applied to an executable in a zoo file." Applying your above argument, we have: The executable code (program) inside a zoo file may do bad things to your system. > 3. SXA's are machine dependent and can only be run/used/extracted > on the target machine for which they were built unless a > separate archiver exists that supports both SXA's and > non-SXA's. A non-SXA can be unpacked and examined on any > machine for which the required archiver is available. Good point. Again, this is why SXA should only be used in special cases. My argument is not trying to prove that "SXA's are just as good as other archives in all cases." I'm just trying to say that SXA's are no more dangerous than other archives... you may just get hit at a different step in the unarchiving process. IMHO, anyway. /\=====================================================================/\ \/ Reality: Steve Snodgrass |"Hand over hand/Doesn't seem so much/ \/ /\ -^-^- Cyberspace -^-^- | Hand over hand/Is the strength of the /\ \/ GRX1042@uoft02.utoledo.edu| common touch" -Rush, Hand Over Fist \/ /\ GRX1042@uoft02.BITNET |"If it's broke, send it back. If it /\ \/ uoft02::GRX1042 (DECnet) | works, take it apart and find out why." \/