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.
G'day David / PQA,
David Golden wrote:
Just because it's a bizarre Perl challenge (and I tend to like those),
I took a hack at what a command line '-MRequires::re::taint" would
need to do in order to force "use re 'taint'" in all modules
subsequently loaded.
Gosh. That's a lot less code than
G'day Hilary,
chromatic wrote:
(Want a heuristic which finds *actual* bugs in almost every module ever
written? Check the use of eval and subsequent $@ testing, or the use of
ref(), or SUPER::whatever(), for example.)
Hilary Holz requested:
Could you expand a bit, please (or provide pointe
Just because it's a bizarre Perl challenge (and I tend to like those),
I took a hack at what a command line '-MRequires::re::taint" would
need to do in order to force "use re 'taint'" in all modules
subsequently loaded.
I've attached a sample module to do just that and some sample code.
To try it,
Ovid,
> Are you on the latest version of Test::Deep?
Ah, yes. That fixed it. Thanx!
> There are issues with
> previous versions having an isa() sub causing strange failures.
Yeah, I saw something about that on the list, but it didn't occur to
me that having a strange isa() could cause this p
On Tue, Jun 24, 2008 at 4:06 PM, Hilary Holz <[EMAIL PROTECTED]> wrote:
> On 6/23/08 11:24 PM, "chromatic" <[EMAIL PROTECTED]> wrote:
>
>> (Want a heuristic which finds *actual* bugs in almost every module ever
>> written? Check the use of eval and subsequent $@ testing, or the use of
>> ref(), or
On 6/23/08 11:24 PM, "chromatic" <[EMAIL PROTECTED]> wrote:
> (Want a heuristic which finds *actual* bugs in almost every module ever
> written? Check the use of eval and subsequent $@ testing, or the use of
> ref(), or SUPER::whatever(), for example.)
>
Could you expand a bit, please (or provid
On Jun 24, 2008, at 11:41 AM, brian d foy wrote:
Yes, those metrics are telling you how to write your code and I wish
they weren't part of CPANTS either.
And all of this again points out that CPANTS is not really aimed at
anyone but the CPANTS test crew.
You know what'd be swell? If CPA
On Tuesday 24 June 2008 02:08:00 Paul Fenwick wrote:
> 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 pro
G'day brian / pqa,
brian d foy wrote:
In article <[EMAIL PROTECTED]>, Paul Fenwick
<[EMAIL PROTECTED]> wrote:
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 suggesti
In article <[EMAIL PROTECTED]>, Paul Fenwick
<[EMAIL PROTECTED]> wrote:
> 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
In article <[EMAIL PROTECTED]>, Paul Fenwick
<[EMAIL PROTECTED]> wrote:
> > I'm very much not happy to get bug reports and test failures and big red
> > bars
> > against my distributions because an automated heuristic which applies only
> > to
> > some cases decided that it knows better about h
In article <[EMAIL PROTECTED]>, Paul Fenwick
<[EMAIL PROTECTED]> wrote:
> * Does anyone think this is a bad idea?
I think it's an exceedingly bad idea.
The more things I have to pay attention to in CPANTS, the less likely
that I'm going to do anything about it. You might like using it, but
I'm
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
G'day David,
David Golden wrote:
Except "use re q/taint/" is lexical. So if some module isn't itself
reading data from a potentially tainted source, then it really doesn't
need to bother with this. That's not the same as strict and warnings,
which always apply to my code.
Ah! But this is n
On Tue, Jun 24, 2008 at 5:08 AM, Paul Fenwick <[EMAIL PROTECTED]> wrote:
> 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 tha
On Tue, Jun 24, 2008 at 3:50 AM, Paul Fenwick <[EMAIL PROTECTED]> wrote:
> Unfortunately while the code may do nothing useful to *your* modules per se,
> it's extremely useful should any be using your modules in a program that
> uses taint mode and wants to be careful about their data. It's rather
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 w
* chromatic <[EMAIL PROTECTED]> [2008-06-24 08:30]:
> On Monday 23 June 2008 22:57:26 Paul Fenwick wrote:
> > * Does anyone think this is a bad idea?
>
> Absolutely.
>
> > Is there someplace this should be going besides from CPANTS?
> > It's definitely a common mistake that module authors can
On Tuesday 24 June 2008 00:50:27 Paul Fenwick wrote:
I forgot to respond to another portion of this post; I apologize for double
responses.
> > I'm very much not happy to get bug reports and test failures and big red
> > bars against my distributions because an automated heuristic which
> > appl
On Tuesday 24 June 2008 00:50:27 Paul Fenwick wrote:
> > I also hate to get bug reports saying "You should add this line of code
> > even if it does nothing useful to all of your modules, because it's not
> > there!"
> Unfortunately while the code may do nothing useful to *your* modules per
> se,
G'day chromatic / QA,
chromatic wrote:
I also hate to get bug reports saying "You should add this line of code even
if it does nothing useful to all of your modules, because it's not there!"
Unfortunately while the code may do nothing useful to *your* modules per se,
it's extremely useful sh
22 matches
Mail list logo
