On Jun 24, 2008, at 9:59 AM, David Golden wrote:
On Tue, Jun 24, 2008 at 8:05 AM, Paul Fenwick
<[EMAIL PROTECTED]> wrote:
I don't see why some subroutine N levels down the call stack in some
utility module should be expected to preserve taint on data you
didn't
check when you received it.
I think this is the crux of our disagreement and for me it's a
practical issue, not a principles issue. I think that since Perl
doesn't allow one to turn off regex untainting globally, that it's
unreasonable (unrealistic?) to expect every module in your
prerequisite tree to do it for you. Therefore, practically speaking,
you can't make any assumptions about taint status so you should manage
it locally where you have control.
This is the most important point of the conversation so far. Paul's
"use re 'taint'" solution only works if *everyone* participates.
That's simply not going to happen, because CPAN is too anarchic to
hope for that. All you need is one module, N levels deep to not "use
re 'taint'" who should have, and it's suddenly your weakest link.
That's not a good situation.
I'll make a blanket statement that I think is pretty non-
controversial: technological change that requires broad participation
is doomed to fail unless there is a big incentive for that change.
CPANTS and Perl::Critic scores are not big incentives. To many,
they're not even small incentives.
I'm perfectly willing to accept a "use re 'taint'" policy in P::C,
but I'd push for it to be a low severity policy -- P::C is designed
to be inclusive without being pushy (except when it's important to be
pushy). Instead, the obviously correct solution is to fix untainting
to be deliberate instead of a side-effect of a common operation. 5.12?
Chris
