Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!tut.cis.ohio-state.edu!pt.cs.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu!vd09+
From: vd09+@andrew.cmu.edu (Vincent M. Del Vecchio)
Newsgroups: comp.sys.mac.misc
Subject: Re: Don't post stuff using stuffit
Message-ID: <8bTek_u00aw301AtdE@andrew.cmu.edu>
Date: 31 Dec 90 03:10:02 GMT
References: <40227@nigel.ee.udel.edu>
Organization: Carnegie Mellon, Pittsburgh, PA
Lines: 68
In-Reply-To: <40227@nigel.ee.udel.edu>

I'm not sure I understand exactly how StuffIt checks for viruses.  Launching a
(configurable) virus-handling application when a virus is discovered sounds
like useful behavior, but I don't understand how the detection is done.  Mr.
Johnston says that it has a Gatekeeper- or GKAid-like mechanism.  (I'm not sure
which and they are quite different.)  First, I don't understand how the process
works because all (known) Mac viruses reside in resources and a compression
program has no way to look at resources during the decompression process,
during which it should be using a linear write of the resources in the data
fork.  Of course, the program could open the resource fork after it was done
writing it, but then it could make itself susceptible (I think) to WDEF-like
virii.  Therein would lie the advantage of having a GKAid-like system built
in--but I think GKAid (I could be wrong about this) only looks at Desktop
files.  It certainly only looks for a very specific and small subset of the
known and possible virii.  (GKAid catches WDEF; does it also catch MDEF/CDEF?
I don't recall; I've never seen either of the latter.)  And as to emulating the
functionality of Gatekeeper itself, the power and generality of Gatekeeper lies
in its passive approach to virus detection.  Gatekeeper detects things when
they try to spread.  This usually requires that an infected application or
system be started up.  I don't think it is practical for StuffIt to start up an
application in order to detect whether it is infected or not; it would be
simpler just to launch Disinfectant.  The only other reasonable alternative to
virus-catching besides the passive approach is (surprise) the active approach,
but until we have something which is artificially intelligent enough to do the
work of determining whether an arbitrary segment of code is virus material or
not, this method depends on looking for known viruses, with regular updates
when new viruses appear.  As has been noted, Stuffit is not updated frequently
enough to make such an approach reliable.  So until System 7's IAC, or John
Norstad supplies an "engine" to do virus-checking from within other programs (I
think personally that the former is much cleaner than the latter, although it
does require waiting for 7.0 :-(), I don't much see the point of virus checking
in compression programs.  Personally, I don't often give copies of stuffed
programs directly to friends, and almost never do that without having used the
program first...  And if I detect a virus in downloaded software, I will check
the source.  On top of this, I find that it is extremely rare that I ever
download an infected archive from anywhere anyway.  I think this is a tribute
to the integrity and carefulness of the people who contribute to and work with
the download sites I deal with.  (Getting a little sidetracked here.)  So I
think that an IAC method which interfaces to the normal virus checking
interface would be great, but anything else is likely to be sub-standard.

>( I was particularly glad to see that StuffIt Deluxe allows alternate format
>handling to be directly incorporated as extension modules.)  I look forward
>to replacing the 4 plus megs of PD dearchiving software that currently
>resides redundantly as stand-alone binaries or .exe files on my hard disk.

Surely you exaggerate!  The only compression or decompression programs that
take up more than 100-150K are, ironically, the latest versions of Stuffit.
Most of them don't come anywhere near that.  I collect these things, and, not
including the latest versions of Stuffit, I don't have anywhere near 4 megs for
the Mac.  Less than 1 meg, I think.  And PC binaries are even smaller, in many
cases (isn't the latest PKZIP about 40K?).

>Why not MacCompress?  It's free.
Have you compared MacCompress with other programs in terms of compression and
speed?  Unix compress is really getting outdated as well (in terms of both
compression AND speed, though the latter is rarely noticed as Unix boxes get
faster and faster and some newer methods are even slower.  Personally, I never
use compress any more under Unix--I uncompress and then use either LHarc or
Squeeze, which uses something called Miller-Wegman encoding.  Unfortunately,
neither is nearly fast enough to run reasonably on a Mac, though Stuffit Deluxe
tries the former.

Just my two cents... Whenever people start talking compression, I have to put
them in somewhere.  In case you can't tell, my preference for a Mac compressor
is Compactor...

-Vince Del Vecchio
vd09@andrew.cmu.edu