G'day chromatic,
chromatic wrote:
I find it difficult to believe that you've audited all of my
publicly-available code in the past 90 minutes to know exactly how much even
uses regular expressions,
My original suggestion clearly should have come with some qualifications.
Obviously modules which don't use regular expressions at all aren't going to
be untainting data by accident through regexp matches. Under such a
theoretical test, these modules can be excluded by default.
> let alone on data that could possibly come from tainted sources.
This has me confused.
As the user of a module, it's possible for me to pass in tainted data. The
module doesn't know from where it's been sourced. However, unless the
*intent* of the module is to untaint this data, anything derived from that
data should probably remain tainted. Likewise, unless it's the purpose of
the module is untaint incoming data, anything the module reads from an
external source should probably also remain tainted.
At the moment, the default behaviour of regular expressions makes is very
easy to untaint by accident, which is unfortunate. I even remember (a very
long time ago) when CGI.pm used to untaint by accident, which was extremely
unfortunate. Most module authors don't even think about taint mode when
writing their code, because most module authors don't which makes catching
this sort of behaviour that much more difficult.
Yes, taint mode isn't an iron-clad guarantee of security, and if you don't
trust a module, don't use it. However taint mode can be a useful safety
net, and for me it would be nice if more people were aware of it and how it
interacts with their code.
Some of them are even *useful*. I like those. The useless distracty ones and
the actively harmful ones -- not so much.
This is the core of the whole automated kwalitee metrics debate, isn't it?
The metrics are subjective, one person's useful heuristic is another
person's painful annoyance.
It's clear that my idea is going to easily fall into the painful annoyance
category, so I'm withdrawing the proposal to add it as an optional CPANTS
test for now.
On that note, surely we could save a lot of anguish with regards to many of
the CPAN tests just by making the optional ones[1] actually optional? As a
completely off-the-bat suggestion that could be controlled by META.yml:
cpants:
disable:
- has_test_pod_coverage
- uses_no_re_taint
- valid_gpg_siganture
enable:
- included_in_slackware
- won_poetry_competition
- includes_Tolkein_quote
My apologies if this has already been discussed and I've missed it.
Cheerio,
Paul
[1] Or even all of them?
--
Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia | Fax: +61 3 9354 2681
