so I have to use both -T and afterwards pass the untainted values to DBI placeholders?

It all depends where your data are coming from. If the data you put in the database is not fully trusted then you should use taint mode and untaint them to make sure they fall within the limits of what is acceptable. Then you pass them to the database using placeholders. If your untainting is comprehensive then the placeholders are probably superfluous, but I find using placeholders in any case more clear and easy.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

My blog: Imperial Deltronics

i'm not a master of DBI nor a Taint one, but you should understand the distinction between them. you MUST use placeholders when DBI is involved. is a good practice should never be avoided even if you are the only user of the application, in my opinion and experience.

Taint mode is whole another story. it assume that all, and i say all, input coming from outside the source code of your Perl program is evil. Evilness is viral so if you mix presumed-evil-data with other data the result is another evil-presumed data. Taint mode is explained also in Modern Perl.

HtH
L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

Echoing the same thoughts in different words:

“Taint mode” is a semi-automated way of recognizing when the value in some variable came from, well, “outside of this application.”   The real advantage of this feature is that it can also track how other data can become tainted through “an encounter with” tainted data.   This is quite difficult to do through static source-code analysis, but Perl does it very effectively through the use of an attribute of the individual data-values themselves as they pass through the perlguts of the system.   Instead of trying to analyze the program at a source-code level, the interpreter tags the pieces of data, themselves.   There is basically no at-runtime cost in doing it this way, and the results are extremely effective.

Meanwhile, “placeholders” are a feature of the SQL language which allow you to define “input variables,” so to speak, for SQL statements.   In the places where you would ordinarily put a literal value (a number, a string, true or false ...), you instead put a question-mark.   You then prepare() the statement in the usual way.   Each time the statement is executed, values corresponding to each placeholder must also be supplied.   The SQL statement itself does not change.   Not only is this more efficient (because the statement need be prepared only once), it is more secure, since the SQL language-parser never “sees” or considers (as potential SQL text ...) anything that those input variables may contain.

I think that “taint mode” is best thought-of, and best used, as a data integrity feature.   Think of it, if you will, as a “garbage-in” flag, which helps you avoid creating the proverbial “garbage-out.”   Taint mode allows the Perl interpreter, itself, to flag ... and, if you wish, to outright prevent ... a common cause of unreliable or incorrect data.   Of course you don’t want your system to be hit by the Bobby Tables problem, but you also don’t want “tpyos” in your permanent data records, either.