Jonathan Rockway wrote:
>> True. On the flip side, there's nothing more irritating that flipping
>> PerlTaintCheck On only to find out a crapload of modules don't run under
>> taint. And that's assuming you have control over whether the flag is set
>> of not. :-/
>
> Maybe an example would help me understand this, but doesn't the application
> *itself* know how best to untaint data? If a module were to check everything
> for taint, it would be roughly equivalent to $var =~ /^(.*)$/; $var = $1;
> which serves no security purpose. I think that if you're running with taint
> on, you (the application developer) should be responsible for properly
> cleansing input. If you miss something, you'll want your app to die inside
> the module so you know what your app is forgetting to check. If you don't
> want your app to die, then don't use taint mode, right?
>
> I would certainly be upset if a module, in the interest of taint safety, set
> $ENV{PATH} to qw(/bin /usr/bin) when I wanted to exec a binary
> in /usr/libexec/bin instead. It's up to me to know the specific details of
> my environment, not a generic module.
>
> Regards,
> Jonathan Rockway
> With most modules, I agree. But with utility modules like Module::Pluggable, File::Find::Recursive, etc, not working under taint is a big bummer because they die under -T internally...in code of my immediate control. (Yeah, I know. Patches Welcome) I just found out yesterday that some tests that use Module::Find don't run under -T and the tests die in Module::Find, no in my .t file. So, yes, some modules can't untaint things in a sensical manner. But somethings, like Module::Find shouldn't just go boom under -T either. Like I said, damned if you do. Damned if you don't. -=Chris
signature.asc
Description: OpenPGP digital signature
