in reply to Muse on Digital Signatures in Perl Modules

One way is to just use PGP like you said, which is the only real solution that is generally accepted today. I really wish there was something more formal, as I made a case in Paranoia, NIH, and Beyond about this very issue. There's no easy solution, though, and if it is to be implemented at all, it would have to be put in place at a high level like CPAN.

It is nice that the Perl community is so trusting and open about things, that the risks are very low, but this may change. While living in a community where nobody has to lock their doors may be nice, locking your doors doesn't destroy the community. Being "robbed" might, though, and it would cause people to be more suspect of their friends and associates. Once trust is violated, it is hard to regain. If there was some mechanism to prevent that breach of trust in the first place, we might all be better off.
  • Comment on Re: Muse on Digital Signatures in Perl Modules

Replies are listed 'Best First'.
Re: Re: Muse on Digital Signatures in Perl Modules
by John M. Dlugosz (Monsignor) on Jul 09, 2001 at 07:06 UTC
    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.
[reply]
      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 Hack1

      Ken Thompson described this virus2 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.
[reply]
[d/l]

        This was covered in Ken Thompson's talk Reflections on Trusting Trust. This first appeared in an issue of CACM. Here's an online copy. It's a fascinating read, a classic that all programmers should know.


        --
        g r i n d e r
[reply]
        To the best of my knowledge, much of this is an urban legend. Ken mentioned that he had thought of the idea but never actually implemented any of it. It would make very interesting code to read. How does a C compiler reliably reconize that it is compiling a "login" program and then determine where to insert the alternate password code? The second hack seems even more daunting of a challenge.
[reply]
        Right... not only do you need authentication of the author, but you also need 'correctness' - a warm fuzzy that other users have approved of the code, that it has no bugs / viruses attached. (If it was to be implemented, it could be a warm fuzzy factor sort of like xp here on pm for the correctness of the code...)

        ----
        Zak
[reply]
      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

[reply]

In Section Meditations