Monday, February 10, 2003

Virex: How not to use Open Source Software As everyone [hopefully] knows by know, the recent release of Virex 7.2 conflicts with Fink in a nasty way. If one is installed and you install the other, the first becomes dysfunctional. For the record, Fink had the particular hunk of territory that is in conflict staked out long ago. However, the depths of McAfee's mistake in packaging run deeper than just using shared libraries that are installed in the wrong location: They depend on shared libaries installed outside of the app wrapper in a fashion where the installer will put the libraries in the wrong location if you attempt to install into some folder other than a folder on the boot volume. Virex ships with several OSS based libraries beyond just the libCurl mentioned in the README / licensing section. Licenses for the other libraries are not included. Source to the additional libraries is not included, nor does there seem to be a way to download it. The package also includes elements that are installed into /usr/local/vscanx, /usr/local/share, /Library/Documentation, and /Library/Frameworks/. If they really wanted to fix Virex, everything not in the application folder should go into the framework. In reading the support thread at McAfee, McAfee is aware of the problem and will hopefully address it soon. Ben Hines posted a number of particularly informative articles within the aforementioned forum. In particular, he mentioned the presence of the install_name_tool command in the OS X Development Tools. I was not aware of this command. With it, it should be possible to include any shared library or framework within an app wrapper, regardless of whether or not you have everything necessary to recompile the dylib or framework! Now that is a very useful trick indeed! Then again, it may only work if there are no intra-library dependencies. I'm not sure if install_name_tool can be used to fix, say, the four libraries that Virex picked up from Fink such that the dependencies between the libraries would be handled correctly. Of course, all of this raises some serious quality control questions regarding Virex. In particular, if such an egregious mistake-- multiple mistakes, really-- was made during the building and packaging of virus protection software that will run as root and scan an entire filesystem with the capability to seek out and destroy anything it wants, can I really trust the software? I'm going to assume not until a new version is released and the rest of the world gives it a test for a while. In general, I don't do much of anything that puts me at risk for viral infection. I generally practice safe computing. I will probably still continue to use Virex to identify the various random Windows virii that my parent's friends seem to contract on a regular basis (In this mode, it doesn't need root privileges to read a file). My mom now laughs at her friends every time they pay another $200 to have their computer "fixed" because of a viral infection (fix == reformat, reinstall). 2:45:07 PM