Re: Debugging a module that's failing under taint mode

G'day Bod,

++ for seeking general understanding and guidance rather than putting your hand out for a specific solution.

Look through "perlsec - Perl security" to get a feeling for causes of taintedness.
Review your code for places where those causes might exist.
"perlsec: Laundering and Detecting Tainted Data" should give an idea of how to deal with potential problems.
See also "Scalar::Util::tainted()".

As a general rule, you should be checking for taintedness in your module's tests, rather than discovering it later when you use the module. Given a module, Some::Module, which lives in /path/to/Some-Module/, I would typically have something very close to this as my first test (/path/to/Some-Module/t/00-load.t):

#!perl -T

use strict;
use warnings;

use Test::More tests => 1;

BEGIN { use_ok('Some::Module') }

diag "Testing Some::Module $Some::Module::VERSION";
[download]

— Ken

Comment on Re: Debugging a module that's failing under taint mode Select or Download Code

Replies are listed 'Best First'.
Re^2: Debugging a module that's failing under taint mode by Bod (Parson) on Jul 01, 2021 at 22:40 UTC
As a general rule, you should be checking for taintedness in your module's tests, rather than discovering it later when you use the module Would you be writing tests for a single purpose module? In other words, a module that only ever gets used with the same 3 related scripts.	[reply]
Re^3: Debugging a module that's failing under taint mode by eyepopslikeamosquito (Archbishop) on Jul 02, 2021 at 00:40 UTC
Would you be writing tests for a single purpose module? Dear Bod, we've discussed this topic before, on April 1 2021 - where my answer was not intended as an April Fools' joke. In summary: You should write your tests before you write your module - or while you are developing it This is because the act of writing the tests improves the module's design, especially its interface.	[reply]
Re^4: Debugging a module that's failing under taint mode by Bod (Parson) on Jul 02, 2021 at 16:47 UTC
my answer was not intended as an April Fools' joke I didn't think it was :P As this module is not much more than a wrapper around Template and really cannot be used anywhere other than within the website that it is written for - really...it cannot - I didn't think tests would be needed because there is no end user as such. Time to revisit that thought...	[reply]
Re^5: Debugging a module that's failing under taint mode by kcott (Archbishop) on Jul 02, 2021 at 23:56 UTC
Re^6: Debugging a module that's failing under taint mode by eyepopslikeamosquito (Archbishop) on Jul 03, 2021 at 10:41 UTC
Some notes below your chosen depth have not been shown here
Re^6: Debugging a module that's failing under taint mode by Bod (Parson) on Jul 04, 2021 at 18:20 UTC
Some notes below your chosen depth have not been shown here
Re^5: Debugging a module that's failing under taint mode by jo37 (Deacon) on Jul 02, 2021 at 20:00 UTC
Re^3: Debugging a module that's failing under taint mode by stevieb (Canon) on Jul 01, 2021 at 22:45 UTC
Would you be writing tests for a single purpose module? In other words, a module that only ever gets used with the same 3 related scripts. Yes, with 100% certainty I would. Besides, "only ever gets used with" are famous last words.	[reply]
Re^3: Debugging a module that's failing under taint mode by kcott (Archbishop) on Jul 01, 2021 at 23:37 UTC
I write tests for every single module I create. That includes personal and $work modules. And the first one is always `00-load.t`. Writing tests is extremely important — I can't stress this strongly enough. Run '`make test`' every time you change `Module.pm`; that provides a regression test. Now write one or more new tests that address whatever changes you made. If you're only changing a test, or want more specific feedback from a test, use '`prove -vb t/whatever.t`'. It might seem like extra work but, in the long run, it will save you much time and frustration. If you use something like Module::Starter, some tests will be automatically written for you; you can write generic test templates which you copy to '`t/`' and then just do a global substitution, e.g. `s/___MODULE_NAME___/Module::Name/g`; you can write boilerplate tests which you can just copy and leave as is (see '`t/99-02_manifest.t`' in "Re: Perl tools for making code better" for an example — that's the first block of code; the filename is mentioned further down). I absolutely concur with ++stevieb's "famous last words" comment. — Ken	[reply] [d/l] [select]


No such thing as a small change
	PerlMonks