in reply to
A Fit on NIH
Certainly, for myself at least, getting modules off of CPAN and
installing them "blindly" is something that I do quite often. I
don't develop on just one machine, so to keep things managable,
I use the "cpan" program, which does exactly what I would do
anyway. Examining the source code with a fine-toothed comb on
every system is impractical, especially considering how many modules
I might need on a given project.
Can you afford the time to check through CGI.pm every time you
install it, examining it from top to bottom, looking for "evil"
It's not like you're even going to see them either, as they
could be mashed up in some unusual and deceptive format, the dark
side of Obfuscated Perl, if you will.
It is true, though, that the possibility of a module as popular as
"infected" in this way is slim, it is still non-zero.
Fortunately, there is an extremely high possibility
that someone else in the Perl community will discover the problem
before you do.
Someone will take one for the herd, and the rest will survive.
I'm not working on some ultra-top secret military project where
paranoia is not just a delusional fantasy, but a job requirement.
In that case, I would certainly be curious about just what they
are putting in the modules these days, and that is assuming I was
bold enough to use "open-source" software in the first place.
The "ftp; tar xvzf; make; make install" routine, and its equivalent
on other platforms, is generally accepted as "the way things are done"
, at least in the UNIX/"open-source" community. Few question the nature
of it on a fundamental level, at least to the extent that any real change
A non-intrusive, user-friendly, and low-impact addition to this methodology
could be embraced, not only to extend the reach of Perl and other similar
projects into a broader market, but to boost the confidence of the existing
community in the quality and security of code that they are using.
Food for thought:
The CPAN system is about as "official" as you can get wrt. Perl modules, so
any "effort" should be focused there. Consider something not altogether unlike
what MS is doing with their "COM" objects:
- CPAN signs all modules that it "publishes" to ensure that it
it arrived on CPAN through proper channels and didn't just curiously
- All authors sign their modules with keys that are published through
CPAN, or, better yet, a "trusted third-party" such as VeriSign or equivalent.
- The modules are examined/tested by a group of trusted code reviewers
and are signed only if they pass.
A program/module such as cpan
could be extended to include some authentication
capability which would allow the user to specify the level of "risk" they are
willing to expose themselves to. That is, you would not be able to install
untested modules, unsigned modules, or what have you, should you elect to be
Implementations could also be "paranoid", such as:
use Module::Security qw(tested signed); # Example name
The more casual among us could merely opt out by installing anything anyway, just
like they always do, without concern. The paranoid would avoid any unsigned modules,
just like they always do, but at least they would be able to use Perl and a selection
of its modules that are rigorously checked.
A system such as this could work, assuming Perl itself isn't part of some
Illuminati-style global conspiracy.
Which it isn't.