Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Monday April 24, 2006
03:01 PM

Is Module::SafeVersion a waste of time?

[ #29436 ]

Most code which attempts to find the version number of a given module either uses a naive regex, uses "eval" on the version line, or loads the module and calls $module->VERSION.

I'm writing Module::SafeVersion which attempts to do this correctly, but it may never get released. I'm employing a combination approach of using a rather complicated regex along with some "cleanup" code to handle the majority of cases. Currently it properly extracts about 98% of the versions of modules installed on my laptop. However, the special cases are significant and I can't ignore them.

I can try to continually expand the regex and the cleanup code, but I'm sadly beginning to think that what needs to be done is to build in special cases for those modules which have jumped through ridiculous hoops to generate their version numbers. Let's look at some examples:

# From SOAP::Lite
$VERSION = sprintf("%d.%s", map {s/_//g; $_} q$Name: release-0_60-public $ =~ /-(\d+)_([\d_]+)/)

# From SQL::Abstract
$VERSION = do { my @r=(q$Revision: 1.20 $=~/\d+/g); sprintf "%d."."%02d"x$#r,@r };

# From CPAN
my $VERSION = sprintf "%.2f", substr(q$Rev: 245 $,4)/100;

Schwern argued that this entire module is the wrong approach. Specifically, if eval'ing a version string is a problem, this implies that you already have bad code on your box and the version string is the least of your problems. PAUSE apparently runs in a chroot jail, so the only folks likely to be bitten by a version string attack would be smoke testers. Thus, if I have code on my box, it should automatically be viewed as trusted. Thoughts?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I'm not sure if this is indeed the wrong approach. I agree that once you have a module installed on your system, it should be safe to eval. (Was it safe to install anyway? How can you be sure about that, about any module on CPAN?)

    What I do have doubts about is whether you can be sure that this one line is all you need. Perhaps some author spread the statement over two lines? Surely that is valid in Perl.

    Yes, loading the module and calling $module->VERSION (or checking ${"$module\::VERSION"}, with strict
  • The problem of course is that of containment.

    While it is alright for people to SAY that "It's installed so you have to trust it" that's not going to be enough to satisfy tainting. Tainting quite rightfully doesn't care WHY, it just enforces the rules.

    Look at other situations.

    Imagine you have a module open in an editor, and the editor wants to intuit the version of the code. The only option available is to apply the same unsafe execution methods.

    This, of course, is rediculous, because as (I hope) I've alread
  • I am quite sympathetic to Schwern’s point of view and was actually thinking of arguing the same.

    But I suppose there’s value in solving this, anyway.

    Question: would it not work better to eval the code in a Safe compartment with all opcodes disabled save for assignment, subst/matching, and a few popular other ones?

    Also: that name is horrible. I thought it was going to have something to do with picking a safe version of a module. You want something like Module::ExtractVersion::Safely, maybe.