Based on other discussions over the past weeks, I've been thinking about how to "sign" a module so you know it came from me and has not been altered or substituted.

Here is a possibility:

The simplest thing is to use PGP to produce a separate .sig file, and distribute that along with the .pm file.

But, why not find a way to embed it in the same file? So, use a specially-named POD paragraph to hold a signature block. A simple program will read a file, throw away that sig block, normalize end-of-line characters, and feed the result to PGP, then insert the new sig block into the original (un-normalized) data.

The normalization is done so that people can sign and verify on different platforms. FTP or Unzip may change line endings, and don't affect the meaning or appearance of the script. Anything else that needs to be normalized for this issue?

The sig block would contain a line stating what it is, the normal base64-encoded PGP signature that's used in email, plain text for the signer's name, and a SHA-1 hash line (base64-encoded) of the same input that was signed.

The latter is a way to do some checking even if you don't have PGP available. This won't detect fraud like a digital signature, but will detect the common case of someone changing something and not updating the version number or release information.

Meanwhile, it's possible for a Perl program to automatically check the signatures for modules it loads. I'm not saying you always want to do that because of performance issues (though MS thinks its OK with .NET, and Java has something like that), but you could. Another thing is to automatically scan and verify the library directories that contain the .pm files, along with your daily backups and virus scans.

Any thoughts on this?

—John

  • Comment on Muse on Digital Signatures in Perl Modules

Replies are listed 'Best First'.
Re: Muse on Digital Signatures in Perl Modules
by tadman (Prior) on Jul 08, 2001 at 22:43 UTC
    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.
[reply]
      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]
        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]
Re: Muse on Digital Signatures in Perl Modules
by Abigail (Deacon) on Jul 10, 2001 at 00:55 UTC
    First of all, there's no point for Perl to always check the signature of a module when loading the module. If you are unwilling to trust what is on your local disk, you should not trust perl itself either. And if you cannot trust perl, why trust whatever it checks?

    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

[reply]

Back to Meditations