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" function calls? 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 CGI.pm becoming "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 is effected.

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 appear.
• 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 exceptionally paranoid.

Implementations could also be "paranoid", such as:

    use Module::Security qw(tested signed);    # Example name

    use CGI;

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.

Right?

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.