Wandering Thoughts archives

The changing assumptions about viruses in email

Once upon a time, back at the dawn of the virus age, viruses in email tended to come from actual people innocently sending around infected files. Somewhat later, they came from actual people having either their outgoing email modified by the virus or simply having their address books pillaged by the virus, which also borrowed their mail client.

Back in those halcyon days, it made sense to do things like clean viruses from messages (leaving the rest of the message intact) and to quarantine virus-contaminated email. When a virus was just a hitchhiker on a legitimate email message or a real correspondent's email account, the rest of a virus-contaminated message had value and so you wanted to preserve it.

Those days are long gone. Modern virus email is nothing more than a dangerous form of spam, where the entire message is the work of the virus. As such, modern virus contaminated email has no value. There is no point in preserving any part of it for human eyes, and if you do the only thing that you're doing is preserving some of the virus's payload. If your anti-virus software is on the ball the remaining payload cannot actually infect the user's computer, but it can still confuse them (for example, as it claims to be a message from your support organization about how their computer is infected with a virus) and this confusion is essentially intractable and inevitable.

The conclusion is clear to me: anti-virus software that does not completely remove all content of a virus contaminated message is using old and now-invalid assumptions. In the modern age, the only three things that anti-virus software should do is either bounce the message, discard the message, or replace the entire message with a note to the effect of 'there used to be a virus message here but we removed it'. Replacing only parts of the message is now wrong.

(The more I think about it, the more I would erase the Subject: as well as the entire message body.)

PS: possibly most modern anti-virus software does this and our software (or configuration) is just behind the times.

Some yum tricks with distro-sync and --releasever

Suppose, not entirely hypothetically, that you have just upgraded your Fedora 13 workstation to Fedora 14 (with the latest updates) only to find out that your window manager now causes the X server to crash. Seeing as this renders the system unable to start your environment, you would like to find a solution by trying older versions of the X server.

As it happens, yum has added some interesting options since I last read through its manual page; in fact, I found out about --releasever and distro-sync from the Yum upgrade FAQ. Today I exploited them to downgrade packages the easy way, or at least what I thought of as the easy way.

(For details on both of these options, see the yum manpage. If your yum manpage doesn't cover them, you can't use them anyways.)

First off, I tried downgrading the X server to the original release version instead of the updated version:

yum --disable-repo updates distro-sync xorg-x11-server-Xorg

With the updates repository disabled, distro-sync will only see the base release version and will (if necessary) revert the package back to that version. I believe but haven't tested that 'yum downgrade' will do the same thing but in a simpler way.

(These two approaches wouldn't be quite the same if Fedora updates kept around more than one version of packages.)

When that didn't work, I decided that I wanted to revert all the way back to the latest Fedora 13 version of the X server (which I knew worked, because I had been running it):

yum --releasever=13 distro-sync xorg-x11-server-Xorg

I was actually kind of surprised that this worked, but it did. Normally one uses --releasever to go forward to the next distribution, but it works backwards too, and with the distribution set back to Fedora 13 distro-sync will thus downgrade the X server to the latest Fedora 13 version. I would definitely recommend running 'package-cleanup --problems' after doing this stunt.

(As it happened I needed to also revert a bunch of other X server related packages in order to get the Fedora 13 X server to not lock up. The result runs my window manager, though, and so I can now actually start my environment on Fedora 14 and be productive.)

As a side note, one reason that I latched on to distro-sync for doing this is that it was easy to reason about how it would behave. Given a specific repository configuration it was easy to see what the end result of distro-sync be; the only challenge was arranging the right repository configuration. (Of course this was made easier because what I wanted to do could be expressed this way; something like 'revert to the previous update version' would have been completely impossible.)