On Tue, Dec 15, 2009 at 04:17:42PM +0000, Martin Evans wrote: > >> > >> I've no idea what is tainting the returned data but this is reproducible > >> for us here is a small amount of perl. > > > > From memory, perl tainting works on a per-statement basis. If a tainted > > value is accessed during a statement then any new values created by that > > statement are marked as tainted. The 'tainted value seen' flag gets > > reset for each statement. > > > > So I'd guess that you're using a single statement, like a select*_* > > method, to pass the (tained) SQL in and get the result data back. > > I saw that "single statement" mechanism you refer to and there are > references to it in DBI.xs too. I presumed it was talking about perl > statements and not DBI statement handles. However, in this case I was > not using a perl single statement I was doing (and can continue to > demonstrate): > > prepare($sql) <-- tained data went in here > execute > fetchall_arrayref
Tainting is viral. So I'd guess that the new sth and/or attributes etc. created by prepare() are tainted. When they're referenced by fetch*() then the result will be tainted. > Also, I continue to do the same thing I always have in 5.8.8 with the > same module versions where this does not happen so I'm really saying > something seems to have changed between 5.8.8 and 5.10 and possibly in > Perl itself. Probably. Seems like a bug fix. (Arguably the DBI's TaintIn/TaintOut attributes were workarounds for perl not doing the right thing itself.) http://search.cpan.org/~rgarcia/perl-5.10.0/pod/perl5100delta.pod Mentions tainting a couple of times, but nothing obviously matches. Tim.
