Sorry for the delay haukex
I hope we can stop apologizing to each other, sometimes good things take time ;-D
Update 2: Sorry, I should have also said: Thanks for taking the time to work out the SSCCE, I can now reproduce the issue reliably! /Update2
I've made a bit of progress: The issue exists in Perl 5.16, but not in any Perl version after that (same versions of MySQL, DBI, and DBD::mysql).
Unfortunately, DBI and DBD::mysql contain a bunch of XS code. I can only guess that there was some bug in regards to XS code and taint mode in Perl itself or in the interaction between the driver's XS and Perl - whatever it is, it appears to have been fixed in 5.18.
Perl 5.16.3 is now over 8 years old and no longer supported. You may want to ask your webhost to upgrade their Perl. Or, perhaps they already have a newer Perl installed, under a different name such as perl5.XX.
Update: I ran a bisect, and it points to 4bac9ae Magic flags harmonization. However, since this is very internals-heavy, I have no idea if this is a red herring or not. Unfortunately, this is as far as I can go at the moment - my suggestion to get a newer Perl stands.
$ ./Porting/bisect.pl --expect-fail --with-module=DBI,DBD::mysql --no-
+module-tests --start=v5.16.3 --end=v5.18.4 -- ./perl -Ilib -T /tmp/te
+st.pl 'foo@bar.com'
# good: [fd04d42d38f4751b981eb6e9213ee1ab8ef11ea6] final changes for r
+elease as 5.16.3
# bad: [51202371ba68f3f52f13124a3ea1bc3c171e0ee2] add v5.18.4 to perlh
+ist
# good: [559550aea97a776e8aa784032f554f5a717ac19b] include some more d
+ata in new-perldelta output
# bad: [624a1c42c1b67cb5d676986900a9d4acab64883c] clean up vmem.h, rem
+ove unused instrumentation hooks
# good: [12f98b43fb8a44e8dfde5d99489b6a599bb91908] anonsub.t: Improve
+test for [perl #71154]
# bad: [a3d517785b3dcac4f3f7aa5c85386a1a8074f46d] perldelta for Unicod
+e property performance gains
# bad: [7c70caa5333de92b09e138154bed7f78f783be3b] Forbid braces as for
+mat delimiters
# bad: [42409c4069deb2417b838a49810ecbce306a72b9] Stop truncate(word)
+from falling back to file name
# bad: [7ca04d94dfa99b3a611a70d3d9a08aa0ccc1fb04] update Module::CoreL
+ist for 5.17.2
# good: [ac7af3f615eb56bda50bf123662b15779da26826] fix RT#114068 optim
+izer handles MEOL in middle of pattern improperly
# bad: [a3314d5f77f945cb8f418a3f4f09bf8f69bb4c3e] mark blead-only modi
+fications of Compress::Raw::{Bzip2,Zlib} with version bump
# good: [5d8673bca0104a9e3975238e86672281f7f71c03] pp_hot.c: Mention t
+hat pp_grepstart calls pp_pushmark
# good: [c55d2e076a02daf604c28e6725a61c1495171552] perly.y: Remove use
+ of latefree from package foo {}
# good: [6e22b38560ae8c2f1293a7f9bc2709541ea4d528] dump.c: Dump op->op
+_s(labbed|avefree)
# bad: [4bac9ae47b5ad7845a24e26b0e95609805de688a] Magic flags harmoniz
+ation.
# good: [b8a55fe78ae4ecc0a81a2d98dba9fead6df06efb] perldelta updates
# first bad commit: [4bac9ae47b5ad7845a24e26b0e95609805de688a] Magic f
+lags harmonization.
Note: Due to the quirks of git bisect in combination with bisect.pl, the terms "good" and "bad" are actually confusing, as they mean: good=the issue is present; bad=the issue is not present. The test script was the following, with the database being set up as in my example above and the table being CREATE TABLE Person ( idPerson INT, email VARCHAR(256) ); INSERT INTO Person (idPerson, email) VALUES (42, 'foo@bar.com');:
#!/usr/bin/perl -T
use warnings;
use strict;
use feature 'say';
use Scalar::Util qw/tainted/;
use DBI;
my $email = shift;
my %data = ( email => $email );
die unless tainted($data{email});
my ($db_user,$db_pass) = ($ENV{USER}, 'barfoo');
my $dbh = DBI->connect(
"DBI:mysql:database=testing;host=127.0.0.1", $db_user,
$db_pass, { RaiseError=>1, AutoCommit=>1, TaintIn=>0 });
my ($test) = $dbh->selectrow_array(
"SELECT idPerson FROM Person WHERE email = ?",
undef, $data{email});
die "<$test>" unless $test==42;
say "OK!";
