First, the singular form of "virus" is "virus", not "viri". Second, the plural form of "virus" is "viruses", not "virii". Third, there is a cogent discussion of this issue at Morality of posting Perl "virus" code and perhaps how to protect against such viruses at Virus protection for Perl scripts.
in reply to Problem with quotes
Fourth, I don't see why this node should be reaped-- at least let the author take the downvotes. The code is still here, and anybody with half a clue and minimal knowledge of Perl could figure it out anyway. Just for the mental exercise... This script avoids doing a lot of things a good virus might: checking to see if it's root and infecting core modules; checking to see if a script is too small and not infecting it-- a virus() function in a 100 line script might be visible, in a 5000 line script it might go unnoticed; building the function into a BEGIN or END block and shoving it in the middle somewhere (even better if "middle" is in the middle of a big block of POD, if the documentation is stable, a programmer doing maintenance might never look there); then, the sheer size of the added code makes it easy to spot, but this just as easily could've been a fairly concise obfuscated snippet... the sort of thing we might pass off if we saw it in someone else's script (like stuff we downloaded) as either advanced wizardry or cargo-cult code. Finally, this code is not cross-language, but it could easily be modified to work from and infect other scripting languages.
To me, the very idea that we should try to keep a lid on this stuff is counter-productive. Anybody using scripting languages in a professional or other setting where security is a concern needs to be *very* aware of the danger of using foreign code. In fact, as a frequent user of CPAN modules, I have to ask: how hard is it to get a CPAN account? Could someone easily make a throwaway identity and upload a trojaned module? Is someone reviewing all of the code posted to CPAN? It's hardly responsible to spout off things like "use the module" to folks who are busy reinventing the wheel (at least non-core-module wheels) if there is a real security risk involved in doing so.