On Tue Jan 26 03:05:22 2010, schwern@pobox.com wrote:
Show quoted text> AEvar Arnfjord Bjarmason via RT wrote:
> > But regardless I'm open to implementing whatever it is you want, I
> just
> > don't understand what that is. Taint::Util is just a dumb wrapper
> for
> > Perl's SvTAINTED_on() and SvTAINTED(sv), when you do
> > SvTAINTED_on(\%hash) Perl doesn't think another reference to the
> same
> > hash is tainted when you do SvTAINTED(\%hash) later.
> >
> > Do you want the hash to be automatically de-referenced or something?
> And
> > if so isn't that magic that should be implemented at a higher level?
>
> Ideally, I'd like it to just work with whatever XS voodoo is
> necessary.
>
> Let me go into a bit more background.
>
> What's happening is I've written a UNIVERSAL::taint and untaint
> methods and
> I'm using autobox. So %hash->taint and %hash->untaint "work" but I
> suppose
> autobox is using the equivalent of \%hash as the invocant so it
> doesn't work.
>
> You can see the code for that here.
>
14981a82
Show quoted text>
> I was actually surprised that you can set taint on a non-scalar at
> all. My
> original plan was to just make $object->untaint() a no-op and $object-
> >taint()
> die. They'd only really work on autoboxed scalars. I'm not entirely
> sure
> that the ability to taint and untaint non-scalars is useful.
>
> So the alternative is to convince me (or make be convince myself) that
> being
> able to taint non-scalars isn't worth the trouble.
I've never actually used tainting, I just wrote module to deal with it
because I thought being forced to use regexes to deal with tainted data
sucked.
Tainting in Perl was always meant to be used for potentially hostile
external data passed to the program. Perl is passed a soup of strings
from the outside but never complex datatypes. So %ENV would have tainted
strings, getting filehandles like <STDIN> would produce tainted strings
etc.
Internally the interpreter is careful about what gets marked tainted in
the first place and only a selected things can become tainted. E.g. some
manual checking in the ucfirst operator ensures that the result of
C<ucfirst $i'm_tainted> will be tainted as well.
But since Taint::Util is exposing some of perl's guts via things get
more complex. Tainting is implemented via perl's MAGIC facility and you
can attach magic to any scalar, but because perl would never do that
it's not there to back you up.
You can taint(*DATA) for example and tainted(*DATA) will subsequently be
true but if you read from the filehandle via <DATA> you'll get untainted
data.
See
http://github.com/avar/taint-util/blob/master/t/usage.t for a bunch
of these odd edge cases.
If you step back and actually look at why you would even use tainting in
the first place in code like perl5i which is targeted at users it's
because when you taint a value perl will back you up when you use it,
e.g. it will slap your hand if you try to pass a tainted value to
system().
If you taint references perl doesn't offer that protection because it
doesn't know anything about tainted references because it would never
create one. The things that do work like the stringification of
C<taint($t = [])> (i.e. ARRAY(0x11a5d48)) being tainted only work
incidentally.
I think what you should do in your code is to die loudly of someone
tries to taint a reference, and I shouldn't do anything because I'd like
to offer module authors such as yourself the opportunity to shoot
yourselves in the foot if that's what you really want :)
