lphillips@lpami.wimsey.bc.ca (Larry Phillips) (03/10/90)
In <79.25f87ef0@uoft02.utoledo.edu>, grx1042@uoft02.utoledo.edu (Steve Snodgrass) writes: >In article <2675@leah.Albany.Edu>, wfh58@leah.Albany.Edu (William F. Hammond) writes: > >> The only way that I would execute a self-extracting archive is if >> 1) I could afford to have an unexpected crash; >> 2) All of my resources were write protected except for ram: >> 3) I personally knew the creator of the archive and knew about everyone >> with whom the archive creator had shared software. >> It's a dangerous world out there, and there is no point doing unnecessarily >> dangerous things. Self-extracting archives are a safe idea only in utopia >> or within a very secure office environment. They are never a good idea. >> -- Bill > >I'll try not to be insulting, but this is a very stupid attitude. Has it >occured to you that there is basically no difference between executing a self >extracting archive, and extracting some stuff from an archive then executing >that? Either way, you run the same risk that some jerk who is out to cause >trouble created the archive. The archive could even contain fake documentation >and such. In short, there is no secuirty advantage to non-self-extracting >archives. You are insulting. You make the assumption that just because an opinion differs from yours, that it is stupid. Not so. By its very nature, a self extracting archive will be compressed, and therefor encrypted. The only part that would not be encrypted would be the extraction code itself. This means that unless you have a means of checking the extraction part itself very thoroughly, you have no way of knowing if something untoward is going to happen when you run the archive. Since you are treating the archive as an executable by running it, you are immediately at the mercy of the program, which could easily decompress and run any part of the encrypted data. With 'normal' archivers, the archive is being treated as data, and has no control over your machine. A normal archive, having been extracted, may have executables that are suspect, certainly, but they are not executed until _you_ decide to execute them, after checking them to whatever degree you feel necessary _IN THE FORM IN WHICH THEY ARE MEANT TO RUN_. What makes them different from the executable self-extraction archive? Well, for one thing, if they are compressed and/or encrypted, a 'strings' will show a suspicious lack of ASCII text. If they have docs, the output from 'strings' can be compared against the supposed purpose of the program. There are quite a few steps I go through when checking files that are suspect (virtually every new package that comes my way, unless I know its full history). There have been many files that I have put onto a floppy and run from there, after first having disabled the access to the hard drives. I don't do it with every package, but I would feel the need to do it with every self extracting archive, because many of the techniques I use are useless on the archive. Do I want to have to do this with every single archived program that comes around, that I can't properly check? Not a chance bunky. You do whatever yuou want, but please stop calling people stupid because they disagree with you. -larry -- Entymology bugs me. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
grx1042@uoft02.utoledo.edu (Steve Snodgrass) (03/10/90)
In article <2675@leah.Albany.Edu>, wfh58@leah.Albany.Edu (William F. Hammond) writes: > The only way that I would execute a self-extracting archive is if > 1) I could afford to have an unexpected crash; > 2) All of my resources were write protected except for ram: > 3) I personally knew the creator of the archive and knew about everyone > with whom the archive creator had shared software. > It's a dangerous world out there, and there is no point doing unnecessarily > dangerous things. Self-extracting archives are a safe idea only in utopia > or within a very secure office environment. They are never a good idea. > -- Bill I'll try not to be insulting, but this is a very stupid attitude. Has it occured to you that there is basically no difference between executing a self extracting archive, and extracting some stuff from an archive then executing that? Either way, you run the same risk that some jerk who is out to cause trouble created the archive. The archive could even contain fake documentation and such. In short, there is no secuirty advantage to non-self-extracting archives. /\=======================================================================/\ \/ Reality: Steve Snodgrass |"Volts embodied intent, and Amps were the \/ /\ -^-^- Cyberspace -^-^- | runners who carried out those intentions, /\ \/ GRX1042@uoft02.utoledo.edu| against the Ohms." -Gregory Benford, ToL \/ /\ GRX1042@uoft02.BITNET | Sleep is a luxury, spare time a myth. -me /\ \/ uoft02::GRX1042 (DECnet) | Recumbent Amigas - the only way to hack. \/
phorgan@cup.portal.com (Patrick John Horgan) (03/11/90)
Steve Snodgrass said: |I'll try not to be insulting, but this is a very stupid attitude. Has it |occured to you that there is basically no difference between executing a self |extracting archive, and extracting some stuff from an archive then executing |that? Either way, you run the same risk that some jerk who is out to cause |trouble created the archive. The archive could even contain fake documentatio n |and such. In short, there is no secuirty advantage to non-self-extracting |archives. That's why most of us just get sources off the net. I would never execute ANYthing I got off the net, and if source isn't included then I don't get to have it...oh well:) Patrick Horgan phorgan@cup.portal.com
andy@cbmvax.commodore.com (Andy Finkel) (03/11/90)
In article <79.25f87ef0@uoft02.utoledo.edu> grx1042@uoft02.utoledo.edu (Steve Snodgrass) writes: >In article <2675@leah.Albany.Edu>, wfh58@leah.Albany.Edu (William F. Hammond) writes: > >> The only way that I would execute a self-extracting archive is if >I'll try not to be insulting, but this is a very stupid attitude. Has it >occured to you that there is basically no difference between executing a self >extracting archive, and extracting some stuff from an archive then executing >that? Either way, you run the same risk that some jerk who is out to cause >trouble created the archive. The archive could even contain fake documentation >and such. In short, there is no secuirty advantage to non-self-extracting >archives. The thing I don't like about self extracting archives is that it reduces the careful person to the same level as a trusting person. When I get some PD software from an unknown source, I run it through a couple tests after unpacking it, and *before* I ever run it. (I unpack with an archiver I've used for years and trust). Before the new code is ever executed on my system I run a couple strings type programs on it that will pick up ASCII and simple encryptions, and a disassembler. (I don't try to actually decrypt the strings, just detect the presence, which is a whole lot easier) If a program doesn't pass the simple tests, or has large sections of binary that doesn't appear to be 68K code or strings, then I don't run it. A self unpacking achiver removes this option. Because unless I write special strings tools to work on the compressed format, and a special disassembler, I've got no choice but to execute the program. (if I went to the trouble of writing a special strings program I might as well finish the job and write the unpacker! :-) ) >/\=======================================================================/\ >\/ Reality: Steve Snodgrass |"Volts embodied intent, and Amps were the \/ andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Not everything worth doing is worth doing well." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
papa@pollux.usc.edu (Marco Papa) (03/11/90)
I've always regarded ANY self-extracting program as a possible source of a virus, trojan horse or similar animal. As such, I simply refuse to even consider taking a look at ANY program that comes in such formats. When your livelihood depends on the continuous sanity of your machine, one just cannot afford the chance. There are a LOT of nice people out there, but there are a FEW jerks, too. So, be warned. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (03/13/90)
In <90.25fc5fd6@uoft02.utoledo.edu>, grx1042@uoft02.utoledo.edu (Steve Snodgrass) writes: > Have you considered this: given a self extracting archive, you can generally >list the files it contains. Thus, you know immediately that you're just going >to unpack some files, or if the archive is fake. The only current >self-extracting format available on Amiga is PAK (a horrible program, I might >mention) which is capable of listing contents if you have it around. I expect >that Lharc self-extracting format will be available soon, also with listing >capability. This, you can easily check to see what you're executing is really >an archive. You can list the files it contains _IF_ you have the archiver, and if the archiver allows that operation. Of course if you have the archiver, there isn't much sense in having a self extracting archive of something. You also have to trust the archiver to check the archive well enough to be sure that it isn't a trojan disguised as a self extracting archive. When you come right down to it, any program you execute is a potential disaster. Any file you treat as data is much, much less so. I prefer to make my judgements about the safety of a file when it is in the form in which it will be run, in plain code, non-encrypted. For the edification of the fellow who said we were being paranoid, let me say that I probably extract more unknown (ie. not from a Fish disk or from someone I know and trust) files in a week than he would in three months, and it's part of what I do in this hobby; making things a little safer for those who just download, extract, and run things they find online. -larry -- Entomology bugs me. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
chrisl@caen.engin.umich.edu (Chris Lang) (03/13/90)
In article <90.25fc5fd6@uoft02.utoledo.edu> grx1042@uoft02.utoledo.edu (Steve Snodgrass) writes: > Have you considered this: given a self extracting archive, you can generally >list the files it contains. Thus, you know immediately that you're just going >to unpack some files, or if the archive is fake. The only current >self-extracting format available on Amiga is PAK (a horrible program, I might >mention) which is capable of listing contents if you have it around. I expect >that Lharc self-extracting format will be available soon, also with listing >capability. This, you can easily check to see what you're executing is really >an archive. Anyone who was going to go to the trouble of distributing malicious code under the guise of a self-extracting archive could very easily create fake code to mimic a file listing, no? Or even use a real archive and just change the executable code, so it would look, for all intents and purposes, exactly like a real archive. (Sounds a little paranoid, I suppose, but there are a lot of creeps out there...for proof, take a look through the VirusX docs. Those babies didn't write themselves.) -Chris ----- Chris Lang, University of Michigan, College of Engineering +1 313 763 1832 4622 Bursley, Ann Arbor, MI, 48109 chrisl@caen.engin.umich.edu WORK: National Center for Manufacturing Sciences, 900 Victors Way, Suite 226, Ann Arbor, MI, 48108 +1 313 995 0300 "I hate quotations. Tell me what you know." - Ralph Waldo Emerson
grx1042@uoft02.utoledo.edu (Steve Snodgrass) (03/13/90)
In article <10102@cbmvax.commodore.com>, andy@cbmvax.commodore.com (Andy Finkel) writes: > > The thing I don't like about self extracting archives is that it reduces > the careful person to the same level as a trusting person. > ... > Before the new code is ever executed on my system I run a couple > strings type programs on it that will pick up ASCII and simple > encryptions, and a disassembler. (I don't try to actually decrypt > ... > A self unpacking achiver removes this option. Because unless I > write special strings tools to work on the compressed format, and > a special disassembler, I've got no choice but to execute the > program. (if I went to the trouble of writing a special strings > program I might as well finish the job and write the unpacker! :-) ) > Andy, Have you considered this: given a self extracting archive, you can generally list the files it contains. Thus, you know immediately that you're just going to unpack some files, or if the archive is fake. The only current self-extracting format available on Amiga is PAK (a horrible program, I might mention) which is capable of listing contents if you have it around. I expect that Lharc self-extracting format will be available soon, also with listing capability. This, you can easily check to see what you're executing is really an archive. BTW: I'm honored to have this debate with someone of Commodore fame. I guess the novelty of Usenet still hasn't worn off for me! /\=======================================================================/\ \/ Reality: Steve Snodgrass |"Volts embodied intent, and Amps were the \/ /\ -^-^- Cyberspace -^-^- | runners who carried out those intentions, /\ \/ GRX1042@uoft02.utoledo.edu| against the Ohms." -Gregory Benford, ToL \/ /\ GRX1042@uoft02.BITNET | Sleep is a luxury, spare time a myth. -me /\ \/ uoft02::GRX1042 (DECnet) | Recumbent Amigas - the only way to hack. \/
new@udel.edu (Darren New) (03/13/90)
>> A self unpacking achiver removes this option. > Have you considered this: given a self extracting archive, you can generally >list the files it contains. >[...] This, you can easily check to see what you're executing is really >an archive. Actually, the best solution for all would be to have a self-extracting format that could also be recognised by the standard archive program. Something like a paramter to zoo or lharc that would say "Tack a self-extracting header for computer XXX to the front of this archive." and which could be recognised. If you already have the archive program (i.e., zoo or lharc) then just extract normally., If you are less paranoid and you don't have the extracter handy, just execute the archive. If you don't HAVE to execute the archive to extract it then you have the best of both worlds (Hmmm.... cli AND workbench?) -- Darren
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (03/14/90)
In <104.25fdcdd4@uoft02.utoledo.edu>, grx1042@uoft02.utoledo.edu (Steve Snodgrass) writes: >In article <492d7755.1a5bf@moth.engin.umich.edu>, chrisl@caen.engin.umich.edu (Chris Lang) writes: >> >> Anyone who was going to go to the trouble of distributing malicious code under >> the guise of a self-extracting archive could very easily create fake code to >> mimic a file listing, no? Or even use a real archive and just change the >> executable code, so it would look, for all intents and purposes, exactly >> like a real archive. > >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. You miss the point entirely. The purpose of an archiver is to keep a group of files together and to compress them for quicker transmission and less disk usage. In order to use or test any part of an archive, it must be extracted. The files that are extracted could indeed include a virus or trojan, but chances are that anyone having any amount of experience, and a reasonable amount of caution, can _THEN_ make the judgement as to the nature of the contents. Before the extraction of all files, you don't have much to go on. Consider two files such as might come across comp.binaries or comp.sources, one of which is the source, and one of which is the executable for a package. There are folks who will, as a matter of course, examine the source, compile or assemble it, and see how it compares with the binary, running only the version you compiled, if necessary. Make these two files self extracting, and it means that you are at risk from the moment you type the name of the unarchiver, without ever having had the chance to evaluate the contents of the file. A 'safe' method of testing a self extracting file might consist of turning off all hard drives, making sure your boot disk is backed up, and unarchiving using floppies, at floppy speeds. Not for me thanks! I prefer to go that route when I see a suspect set of files or a set of files I cannot properly test, which is in the minority of cases. The basic idea is that anything that is treated as data is relatively safe, but hat anything that is treated as program is a potential bomb. Nothing is stopping you from supporting self extracting archives, writing them, or using them, just as there is nothing to stop me from speaking out against them. I think this horse is dead. -larry -- Entomology bugs me. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
grx1042@uoft02.utoledo.edu (Steve Snodgrass) (03/14/90)
In article <492d7755.1a5bf@moth.engin.umich.edu>, chrisl@caen.engin.umich.edu (Chris Lang) writes: > > Anyone who was going to go to the trouble of distributing malicious code under > the guise of a self-extracting archive could very easily create fake code to > mimic a file listing, no? Or even use a real archive and just change the > executable code, so it would look, for all intents and purposes, exactly > like a real archive. 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. > (Sounds a little paranoid, I suppose, but there are a lot of creeps out > there...for proof, take a look through the VirusX docs. Those babies didn't > write themselves.) I'm not debating the existence of trojans/viruses. However, it's silly to label self-extracting archives as inherently more dangerous than any other archive you might come across. /\=======================================================================/\ \/ Reality: Steve Snodgrass |"Volts embodied intent, and Amps were the \/ /\ -^-^- Cyberspace -^-^- | runners who carried out those intentions, /\ \/ GRX1042@uoft02.utoledo.edu| against the Ohms." -Gregory Benford, ToL \/ /\ GRX1042@uoft02.BITNET | Sleep is a luxury, spare time a myth. -me /\ \/ uoft02::GRX1042 (DECnet) | Recumbent Amigas - the only way to hack. \/
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (03/15/90)
In <cZzv7aK00WB78RFWNb@andrew.cmu.edu>, md3b+@andrew.cmu.edu (Matthew Donald Drown) writes: >My editor doesn't allow me quote, so I will paraphrase a message from >Larry Phillips, lphillips@lpami.wimsey.bc.ca If it is a bad quote, >then please correct me. >"Every program that you execute is a potential dissaster." > >Hmm, you must have a lot of fun using your computer. Are you the type of >person who when they leave the house sees the fact that every time he >crosses the street, he could be dead? There comes a point when it is not >worth checking everything. Do you check all the files that come on comercial >disks? How about the files on non-standard dos? Do you power down before >you use the machine after, say, playing a game? What about files that are >crunched? How do you deal with those, you can't check them for text that >you want, you must trust them. >If you run your computer in a way were half your time is spent checking >for viruses then what is your hobbie? Checking for viruses? > >(I don't know if it me you were talking about when you said, "I download >and extact more stuff in a week, then you do in 3 months." But lets cut >this stupid stuff out. We don't need "Mine is better then yours" wars. Good one Matt... send it to me in email and then repeat it to the net. Well, here's how I answered you. No, I don't check commercial stuff, and I don't check stuff that has come to me via a route that I trust. Files that are crunched get uncrunched before I'll use them, or if I can't uncrunch them, I turf them. Non-standard Dos? Not sure what you mean. I don't know if I was talking about you or not, but I assure you that my comment about how much I download and extract was not a "Mine is better than yours" sort of statement. It was a statement of probable fact, and was quite germaine to the discussion. I am a sysop on Compuserve, and part of what I do is to download and test files that have been uploaded, before making them public. While much of the testing is to check for copyright violations, non-corrupted files, and to see if the package is complete and will run, I also routinely check for nasty files that contain viruses or trojans. In the time I have been a sysop, I have personally found 2 programs that contained viruses, and one that contained a trojan. In finding these, I have prevented at least some measure of pain to the members of the forum and to anyone they pass files on to, and consider the time to check to be time well spent. Other sysops on our forum have had similar experiences. I do a lot of different things as part of my hobby. I spend a LOT of time helping other Amiga owners, both novice and veteran, directly and indirectly. I also program, write articles, and build hardware. It is precisely because I don't get a lot of self extracting archives that I have time to do what I do, because I don't have to take as many precautions when I can treat the file as data, rather than executable, and have a better chance of detecting the nasty ones, with some automated tools. -larry -- Entomology bugs me. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
md3b+@andrew.cmu.edu (Matthew Donald Drown) (03/15/90)
My editor doesn't allow me quote, so I will paraphrase a message from Larry Phillips, lphillips@lpami.wimsey.bc.ca If it is a bad quote, then please correct me. "Every program that you execute is a potential dissaster." Hmm, you must have a lot of fun using your computer. Are you the type of person who when they leave the house sees the fact that every time he crosses the street, he could be dead? There comes a point when it is not worth checking everything. Do you check all the files that come on comercial disks? How about the files on non-standard dos? Do you power down before you use the machine after, say, playing a game? What about files that are crunched? How do you deal with those, you can't check them for text that you want, you must trust them. If you run your computer in a way were half your time is spent checking for viruses then what is your hobbie? Checking for viruses? (I don't know if it me you were talking about when you said, "I download and extact more stuff in a week, then you do in 3 months." But lets cut this stupid stuff out. We don't need "Mine is better then yours" wars. -Matt Drown (md3b@andrew.cmu.edu)
laba-1ei@e260-1b.berkeley.edu (Joseph Chung) (03/16/90)
In article <cZzv7aK00WB78RFWNb@andrew.cmu.edu> md3b+@andrew.cmu.edu (Matthew Donald Drown) writes: [stuff deleted] >Hmm, you must have a lot of fun using your computer. Are you the type of >person who when they leave the house sees the fact that every time he >crosses the street, he could be dead? There comes a point when it is not >worth checking everything. Do you check all the files that come on comercial >disks? How about the files on non-standard dos? Do you power down before >you use the machine after, say, playing a game? What about files that are >crunched? How do you deal with those, you can't check them for text that >you want, you must trust them. >If you run your computer in a way were half your time is spent checking >for viruses then what is your hobbie? Checking for viruses? [Stuff deleted] Would you walk into a dangerous neighborhood counting thousands of dollars worth of cash in your hands? Some people use their computers for fun, others use it for business, most use it for many purposes. A virus is any computer user's worst nightmare. Any damage to a ..say...accounts payable or receivable, would mean the loss of mega $$, house, car,.. etc. This is just one example. If you just don't give a damn while you have very important data in your copmuter, than you only have yourself to blame when something goes wrong. (Backing up is not the only precaution that you can take). I have lost HOURS of work to %$#^!& viruses. If only I had taken a few minutes of prevention every time I used a piece of software, this wouldn't have happened. But I suggest you continue using all the self-extracting files you can Matt. -jc -- You can't win.....You can't break even.....You can't even quit the game! laba-1ei@web.berkeley.edu
fnf@estinc.UUCP (Fred Fish) (03/17/90)
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: 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. 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. 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. (there are more, which have already been stated by others against SXA's so I won't continue the list. Only one argument is sufficient to prove the statement false anyway. >I'm not debating the existence of trojans/viruses. However, it's silly to >label self-extracting archives as inherently more dangerous than any other >archive you might come across. Apparently there are a lot of people that would disagree with you here. -Fred -- # Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA # 1-602-491-0048 asuvax!{nud,mcdphx}!estinc!fnf
grx1042@uoft02.utoledo.edu (Steve Snodgrass) (03/19/90)
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." \/
mikes@lakesys.lakesys.com (Mike Shawaluk) (03/19/90)
In article <270@estinc.UUCP> fnf@estinc.UUCP (Fred Fish) writes: >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: > > 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. > . . . > 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. I beg to differ. In the MS-DOS world, there are several SXA methods in use; three that I can think of are for .ZIP, .ZOO, and .LZH files. In each case, a short program is prepended to the appropriate archive file (for the .ZIP file, there is some internal tweeking, but read on). When this is done, the file is STILL readable by the "normal" utility (i.e., PKZIP and PKUNZIP can be used to read the contents of and/or extract from a self-extracting ZIP file; the same is true of ZOO and LHARC). The only requirement for the utility that does the extraction or viewing is that is look past the initial self-extraction code & "lock on" to the signature that's at the start of the archive part of the file, and decode it from there. In a ZIP file, there are also pointers with the file headers and central directory, which are modified when a file is made into a self-extracting one, such that it's not required to seek over this code; one can seek to the end of the file, back into the centra directory there, and go directly to whatever file or files are required. I know that, in the case of PK*ZIP, that Phil specifically took steps to assure that it would be possible for people to access files in self-extracting ZIP files using the "trusted" tools, for exactly the reasons you and others have mentioned. Again, please do NOT take the intent of this message as one of advocating SXA's (btw, I like that acronym; saves a lot of typing; thanks Fred :-). Rather, I am trying to shed a little light on this whole discussion (I would have done so earlier, but our host here hasn't been allowing postings lately, due to disk shortages.) I would agree with Fred & others regarding a self-extracting format like PAK that is unique to one platform (the Amiga), and that isn't a very flexible tool (and, as a separate aside, doesn't compress all that well either, but then, it wasn't designed to...) - Mike -- - Mike Shawaluk "Rarely have we seen a mailer -> DOMAIN: mikes@lakesys.lakesys.com fail which has thoroughly -> UUCP: ...!uunet!marque!lakesys!mikes followed these paths." -> BITNET: 7117SHAWALUK@MUCSD