Since Perl is shipped as source code, one can look at it and see if it's evil. I'm sure it will be more of an issue as Perl is used for more "mainstream" applications.

Perl may not be "evil", but there have been circumstances in the past where something quite along these lines had occured, but with the C compiler (!) instead:

1984 Ken Thompson's CC Hack¹

Ken Thompson described this virus² as "the cutest program I ever wrote", and since his account of it appeared in 1984, it has become folk law of the information age. Ken modified the source of the C compiler (CC) such that the compiler would detect when it was compiling the UNIX "login" command and hence produce a compromised version of the login command which would accept either a valid password from the system password file, or a particular known password. Effectively giving him a back door to any system whose "login" binary was compiled with his compromised C compiler. This in itself results in a curious situation, despite all attempts to verify the source of the "login" command, it is impossible, once the C compiler has been compromised to build a secure "login" binary.

Not content with this level of subversion, Ken introduced a second modification to the compiler source such that it would detect when it was compiling a new version of itself. It would then incorporate both modifications into the new compiler binary.

This event came as quite a shock to the UNIX community. They were taken completely by surprise.

In all honesty, though, even if you read through every single line of Perl's interpreter code, do you think you could find malicious code even if it were in there? Not likely. It's not like it will have a giant comment beside it that would make it stand out:

/* Here is the EVIL VIRUS CODE that is implanted in every Perl
   Absolutely no peeking. This is not here. */
if (moon == color_blue && day_of_week == 5 && day == 13)
    delete_hard_drive(completely);
[download]

In fact, that hypothetical code would look just like any of the thousands of other lines of code. You would never know.

---

1. Excerpt taken from Linux and the Virus Threat by Shaun Cloherty (Feb 4, 2001)
2. K. Thompson, "Reflections on trusting trust", Communication of the ACM, Vol. 27, No. 8, August 1984, pp. 761-763.

Since Perl is shipped as source code, one can look at it and see if it's evil.

In theory, one can certainly do that. But is it practical? I really wish it would, because then everyone could be a Perl porter! Perl is installed by tens of thousands of people. I'd be surprised if even 5 checked the source to see whether it has some nasty "easter eggs". For modules, it might be a little easier to check (because it's less code), but still, it's not practical at all. Not only do you need to check the module, but also the makefile and the test program(s).

-- Abigail

However, suppose you have massaged Perl such that it will fetch module from the internet and load them for you. (You can do that to some extend with my CPAN module The::Net). Not just source modules, but compiled modules as well. Then just signing is not enough. You signing the module doesn't give me any garantees. I might not know you, hence the signature doesn't tell me anything, or, if I know you and have your PGP public key, I still might not trust you.

You'd need to set up a trust system. Perhaps I don't trust you, but I do trust Mr. Feeble, and Mr. Feeble has vouched you. Then I might be willing to run your code.

Luckely, someone has already thought about this. Brian Ingerson, from Inline::C fame. Last YAPC::NA, there was a meeting on the following Saturday about peer to peer exchange of (compiled) modules. I missed it, but Brian will be at TPC and YAPC::Europe, and has promised he will have the idea more worked out by then.

-- Abigail