Stas Bekman <[EMAIL PROTECTED]> wrote:
:May be you are right, Hugo, in which case perl provides no function to figure :a version number without first loading the module.
Well yes it does, in an untainted environment. And you've shown already how easy it is to adapt that code to a tainted environment when you do trust this particular data source. If you *don't* trust the data source it'll be much harder - either you must be very careful in writing your detainting regexps, or you need to start setting up Safe compartments.
Tainting is in many ways too simple a concept for this, and inevitably will appear sometimes to be too broad a brush and other times oddly selective - in this case, particularly as the same file would be fully trusted by perl if read in with C<use> or C<require>. (Hmm, maybe files from perl's own library hierarchy should always be tagged untainting, whoever opened them?)
I completely agree with you, Hugo. But I'm also sure that you know that when something doesn't work under -T a frustrated user simply turns it off. So:
"Well yes it does, in an untainted environment"
is really, not it doesn't work. I'd rather relax taint checking in certain places, rather than have the user turn it off completely. Certainly documenting the issue should be helpful.
:Besides, no module that ever wants to run under -T environment can use :ExtUtils::MM_Unix->parse_version, because it will break. If you have an :alternative solution, please suggest it.
In your situation, I'd probably duplicate the code. In an ideal world, parse_version() would optionally accept a filehandle instead of a path, and perl would make it easy to hand it a filehandle marked trusted. Further into the future, perhaps perl6 will allow you to get really clever and tag the path itself as "trusted as a path to a file containing perl code" (though I don't think it'll need such cleverness just to find out a version ...).
That's whast I did - duplicated the code.
IMHO, making the user deal with untaining the filehandle just to check the version number is an overkill and doesn't make perl any friendlier.
:Besides, If you are going to say:
:
:require Foo;
:
:doesn't it make Foo trusted enough to make contents of Foo.pm trusted for eval :STRING?
Yes, if you are going to C< require Foo >, it makes sense - you'll be running the code anyway. But that may not be the only situation in which you might want to parse out a version.
It is quite possible my original objection is wrong, and that it would be better to add the detaint but additionally modify the docs to give a clear warning that it'll be running code out of the file you point it at. I suspect though that a) most perl programmers are not aware that you can't find a module's version without running code, and b) that they therefore wouldn't perceive this as a "dangerous sort of thing to do" for which they _need_ to look carefully at the docs.
Again, it may be possible to shoehorn in an extra flag to ask for the detainting, which has the benefits of not changing behaviour for existing programs, and not incurring the detaint cost for them either.
Yes, that sounds like a good compromise, Hugo.
That's said, it'd be great to see the perl test suite run all its tests under -T. I thought we have discussed this about a year ago or so.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
