|Just another Perl shrine|
Re^2: Blatant security problem in certain CPAN module installsby adrianh (Chancellor)
|on May 03, 2004 at 13:49 UTC||Need Help??|
The SIGNATURE is basically only used to verify there are no transmit errors. Using it for any form of verification or accountability only gives one a false sense of security, which is worse than no sense of security, IMO.
It's a little bit more than just a hash. We know that the person who signed it had access to the private key of the individual involved.
I trust code signed by chromatic's private key more than I would trust arbitrary code because I trust chromatic as a Perl author, I trust that the private key that the code was signed with belongs to chromatic, and I think that he guards his public key well.
Is this absolute 100% accurate verification/accountability, no. Is it better than just a hash, yes.
Any module that has a pre-requisite causes CPAN.pm to download more code, if you have configured CPAN to do so, or if you blindly say "yes" when it asks.
Which is why I don't have my CPAN (PLUS in my case) configured in that way. However, if I did it would have been my choice to make.
The point that I was trying to make was that CPAN modules than download and install stuff off their own back should ask first as a matter of policy - not that there is any way to enforce this.
Let's face it - downloading code, any code, from CPAN is potentially dangerous. You're only safe if you have inspected the code yourself, and didn't make a mistake in your inspection. Of course, just inspecting the code you just downloaded doesn't make you safe. When was the first time you audited the source code of perl? How do you know that doesn't have a backdoor? What about your C compiler?
Yes of course. As Gene Spafford says:
The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts.
So instead we have to (hopefully in an intelligent manner) weigh risks and benefits.