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