From the man page

The only way to bypass the tainting mechanism is by referencing subpatterns from a regular expres- sion match. Perl presumes that if you reference a substring using $1, $2, etc., that you knew what you were doing when you wrote the pattern. That means using a bit of thought--don't just blindly untaint anything, or you defeat the entire mechanism. It's better to verify that the variable has only good characters (for certain values of "good") rather than checking whether it has any bad characters. That's because it's far too easy to miss bad characters that you never thought of.

if($input=~/(\d+)/) { $input = $1; }
else{ $input = undef }
[download]

You don't have to copy $1 back to $input either. I only did it to create less variables. You can do $verifiedInput = $1 too. But remember to program around the cases when the regexp matches or doesn't.

Hi sporty,

So there is your problem Read up on the man page, it's far more comprehensive compared to what I'll cut-paste for you....

Looks like I'll have to read up on regexp as well as taint. Also, "what to do" when error messages appear. At present, the user sees some strange message, but I don't see a thing. Maybe a quick email to me, or some (quick) data into MySQL. The problem in this case is we lost an order, because the user can only get _that_ far by pressing "Confirm order". We have no details anywhere of who the person was, not even the email address, let alone the order details. :(

Thanks,

Peter

Welll, all I can tell you is to have your code rigerously tested. have it tested. QA people would test it under various types of load, various types of input and what not. It's prolly a really silly bug somewhere that, w/o the entire script and a lot of time, we can't easily help you with. It's one of those cases where you find out how the error wsa brought around, try and reproduce it and the likes.

Play that funky music white boy..

I imagine that perl worked significantly different there as there are many perl built-ins that don't exist on Win32 :-) But I don't think that's relevant to your problem. It just looks like you have possibly multiple sources of tainted data that you need to untaint before using. The cannonical way to untaint your data is by using a regular expression. For example, your $seq variable is read from a file and is supposed to be a number but perl has no way of knowing this; it's just text read from a file. So, to untaint it:

($seq) = $seq =~ /(\d+)/;     # Just grab the first run of digits
[download]

I imagine that perl worked significantly different there as there are many perl built-ins that don't exist on Win32 :-) But I don't think that's relevant to your problem.

Yes, you're are correct. The migration was Unix --> Linux ; I only mentioned Win32, because I also have Perl installed at home, it saves a bit on bandwidth and testing time, and for teaching myself some more perl. That said, there are a number of things I can't do on the Win32 box. :(

It just looks like you have possibly multiple sources of tainted data that you need to untaint before using.

I've never heard of the word taint before, although if something is "tainted", in english, it is "dirty", so I assume tainted data is "dirty data" ?

The cannonical way to untaint your data is by using a regular expression. For example, your $seq variable is read from a file and is supposed to be a number but perl has no way of knowing this; it's just text read from a file. So, to untaint it:

($seq) = $seq =~ /(\d+)/;     # Just grab the first run of digits
[download]

Great, thanks for the tip on how to untaint :)

Peter