• 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.

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

    use CGI;

Where I work security is a huge issue. What I've resolved must be done before CPAN modules can be used in this enviornment is to create an internal CPAN. Which will allow for several things:

1.) Keep track of who has what versions of which modules on what systems. This has several benefits; Internal points of contact for module usage, Back tracking should a security problem be discovered, revision history, and disaster recovery.


2.) Allows for new CPAN releases to 'cook' out in the world without forcing established applications to run on a new module version just because CPAN has released an upgrade and they moved to a new server.


3.) Centralizes perl user's and distribution, which provides internal avenues for problem resolution that is missing from the accepted practices of this organization. (Who does production call when a perl problem arises?)

I'm not paranoid about CPAN, but I view it as an I.V. from which a large organization must design it's own needle. What you say about code review is very true, and no matter how important security is, the type of code review you speak of is impractical. But like Perl, it's capriciousness cannot be left completely unchecked except at ones own level of acceptable risk.

coreolyn

Don't take what I am saying here as a recommendation, but, I know that ActiveState provides a service called PerlDirect which attempts to address some of these issues. From what I have heard, they do QA on Perl as well as popular modules and bundle them into a special, periodic distribution that is aimed at large corporations.

I have recommended that this service be evaluated by one of my corporate clients, because they give integration testing tasks to people from a "UNIX Core Group" which knows a great deal more about the core of the Solaris operating system than it does Perl. In situations like the one I am describing, it is often up to the individual development teams to perform extensive unit testing on their finished products because the IT department only certifies the modules that are distributed with Perl itself. Needless to say, this is not an optimal solution.

Dave Aiello
Chatham Township Data Corporation

I really like the idea of having a built-in method of verifying the integrity of a module. This could "easily" be done by using a PGP/GPG-style mechanism or simply a built-in method of checking an appended IDEA (crypto-)hash of the source code and/or any XS used by the module.

A really simple way would be to extend the __DATA__ mechanism to also include a __SIGNATURE__ section, which contains an (IDEA)(crypto-)hash of the source code, which can then be checked optionally by Perl against the code and (if available) against a local list of "trusted" keys. Of course, if that list of trusted keys is compromised, all security is down, but if that list can be compromised, bets are that everything else already has been as well.

So, as I see it, a two-fold protection mechanism would need to be in place. One, a public/private key system with CPAN as a central repository for the public keys, so that everybody can check the authenticity of their modules, and a second, global public/private key, owned by CPAN, to check the integrity of every module locally at any time.

OK, so I'll go and take the flak...

I don't think the problem is necessarily with security, I think it is with the total absence of quality control or at least ranking on CPAN.

I use quite a few modules from CPAN, and I am usually pretty satisfied with them... as long as I stick to "reputable" modules. On the other hand a cursory analysis of a somehow random sample of CPAN modules shows, as Dominus puts it so nicely "a lot of crap"!

Now how do I determine that a module is "reputable"? Well I've heard CGI.pm was used by a bunch of people ;--) so it is reputable, then everybody keeps yelling "use LWP!" and "use File::Find" so I guess they are OK too, and MJD's ego is too big to release a piece of crap with his name on, so Text::Template qualifies and if not, Template::Toolkit won a prize so it should be OK. Oh, and there's books about DBI and TK, so maybe I'll add them. Add a couple more and you have the list of those modules I use (or would use) with a reasonable degree of confidence.

On the other hand when I look at the number of XML modules on CPAN and the general level of quality and support you get for them I am a little scared. It goes from a widely used module changing interface and no longer backward compatible without changing major version, to the maintainer of another widely used module disappearing from the surface of this Earth (and thus his module not being able to cope with the aforementioned loss of compatibility), to "things" that are not (and apparently will never be) a complete module stored on CPAN, to (my personal favorite) maintainers unable to support a module because they "will do an internship at Microsoft so (they) won't have access to a computer this summer"... and all of those modules are presented the same way to unsuspecting users.

Now you tell me, how is joe user supposed to know which module he can safely use and which one will result in terrible pain and suffering debugging a module's code? For an unknown module, written by an unknown author, I'd say only thorough testing can help, and I see no shame in weighting this against rewriting the module (or at least the parts of the module that cover the required functionalities).

So yes CPAN is great, there's some great modules and an unbelievable amount of work in there. But there's also a good deal of crap and no easy way to figure out which is what.

That's it for my fit against CIH (CPAN Is Holy) ;--)

I am usually a little wary of COMPILED modules these days, ones that I can't see the implemtation of. But CPAN is and hopefully will always be open source. It seems then that most arguments against CPAN modules that start out with "I do not trust code I didn't write" really become "I don't understand how the module works, so I'll ignore it and write it myself."

And to this DAY, people still insist on keeping this attitude. I guess this is to be expected - maybe MicroSoft has made everyone paranoid about using someone else's code, I mean, do we really know that there aren't any backdoors in MicroSoft's COM objects.

Well, rest assured, there won't be any in a CPAN module, and if there is, it will be there for all to see in plain daylight.

Jeff

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
F--F--F--F--F--F--F--F--
(the triplet paradiddle)

Says jeffa:

Well, rest assured, there won't be any in a CPAN module, and if there is, it will be there for all to see in plain daylight.

Oh? It used to be that when you ran the Makefile.PL for Memoize, you got the following output:

system("rm -rf /");
[download]

(Then there was a three second pause.)

This is only a test.  I did not actually try to erase all your files.
Sorry if you were alarmed.

Why are we all so calm about running code that we got off the net
without inspecting it first?

I would like to call for greater awareness of this problem.  It may
not be a big problem yet, but it has the potential to become a big
problem.  Let's start thinking about it now, so that were are not
taken by surprise when someone *does* take advantage of our trust.

What can be done about this?
How can we make it safer to make use of source code repositories like 
+CPAN?

As an incentive to greater vigilance, the next version of this
Makefile.PL REALLY WILL run rm -rf / one time in one thousand.

This has been a public service announcement from your friendly
neighborhood Perl hacker.
[download]

I still think we don't take this seriously enough. It's not enough to say that the trap will "be there for all to see in broad daylight." People don't look at the code before they run it; even when they do, there's no channel for them to warn others.

I think we need to do something about this. Michael Schwern's CPANTS project looked promosing, but then he abandoned it. I'd like to see peer review of CPAN modules and a database of reviews.

I think we need to do something about this. Michael Schwern's CPANTS project looked promosing, but then he abandoned it. I'd like to see peer review of CPAN modules and a database of reviews.

I thought that was the purpose of the "discuss your module before submitting it" part of the CPAN module procedure.

Putting peer reviews (or, for that part, *any* reviews) of modules in a central place is a good idea, for sure. But who will write those reviews? And should CPAN shoulder the burden of organizing the whole process around it, and take the responsibility for (always possible) errors?

Let's face it - reviewing module code is so difficult and time-consuming that most people prefer to write something new instead (I don't mean reviews like the ones we have on this site under Module Reviews - I mean real code reviews). This is a Bad Thing, agreed. But where is the incentive for people to put their energy into code reviews, when the majority of the community does not value this service?

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

I think we need to do something about this. Michael Schwern's CPANTS project looked promosing, but then he abandoned it. I'd like to see peer review of CPAN modules and a database of reviews.

Did he actually abandon it? Or just disappear without trace for a while?

Belfast.pm was hoping to get heavily involved in CPANTS, but haven't really gotten much futher than setting up our own local CPAN mirror.

I'd love to get something running on this, but my work life has just taken another interesting turn, which may limit my ability to get stuck into this for a while :(

And the perl-qa list is just too quiet...

Tony

Tony

To repeat: "The only possibility of achieving really impressive increases in productivity is using other people's libraries." (Brucke Eckel, Thinking in C++, Prentice Hall, 1995).

IMHO, there is no way you (as a single person) can be sure what happens on your system today. The average computer system and its software components are much too complicated for this. In the time you need to understand the whole system, it will have changed away under your feet. You may be able to understand parts, but even this can be challenging if you work under time pressure.

Perl is a language for getting your job done.

If you want safe hardware, build your own.
If you want real OS security, go for OpenBSD.
If you want signed, vendor-approved code, go for Java.
If you want to guard against every possible known evil, join the ranks of the latest paranoia cult.

But please, let Perl be Perl.

Hm, that got pathetic. Ah, who cares.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

*sniff*
I care, man!

Jeff

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
F--F--F--F--F--F--F--F--
(the triplet paradiddle)

"I don't trust code that I haven't written because I don't know what it's doing to my system."

But Perl is OK? Hmm. Maybe they need their head examined. Did you tell them that perl 5.6.x comes with like 100 modules?

Also, I usually point out the other half of their logic this way: "You are right, you don't know what the module is doing. It likely is doing a great deal of things you never would have thought of on your own."

Then I stop talking to or helping people who still don't get it. Stupid people aren't really worth my time to help, especially if they won't listen to the best advice I have.

--
$you = new YOU;
honk() if $you->love(perl)

The other side of that coin is that a lot of stuff on CPAN is crap, and you might be better off doing it over, depending on who you are and what you know.