develooper Front page | perl.perl5.porters | Postings from February 2017

Status of NO_TAINT_SUPPORT define (Was: Re: Should we considerlocked hashes a failed experiment?)

Thread Previous | Thread Next
Steffen Mueller
February 2, 2017 21:06
Status of NO_TAINT_SUPPORT define (Was: Re: Should we considerlocked hashes a failed experiment?)
Message ID:
On 02/02/2017 06:38 PM, Vincent Pit (VPIT) wrote:
>> No need to be afraid of naming it. It may well be that is
>> the only user of a perl that has taint support compiled out.
>> BUT without any doubt, we'd expend the effort to fix any issues that
>> would come out of this. We have perfectly strongly vested interest in
>> that.
>> We also currently use a very, very sizeable fraction of CPAN (likely too
>> much for our own good, I have to admit), and we have an 8 digit number
>> of lines of code (not including CPAN upstream) written by over a
>> thousand developers (ie. there is no clear alignment with that number of
>> devs on how exactly to do all things, and thus likely exercising more
>> corner cases than we'd like).
>> options are very likely better tested than the majority of other options
>> one might choose to use.
> I understand that this option is useful to you, and that it can be for
> others too.
> But you also have to understand that this is only valid at the scope of
> a company where you have complete control over your whole toolchain. It
> cannot possibly ever be advertised as a supported option that could be
> enabled at the discretion of a vendor, and as such cannot be officially
> supported by the porters.

I mostly agree with that paragraph. But certainly agree that this should 
NOT be enabled by a third party for users. Never.

> How could this option ever be supported when the humongous pile of code
> in the world that uses taint mode would see it behaviour change suddenly
> depending on the value of a compilation directive - and with security
> implications to boot. I mean, there's a reason even PHP realized
> magic_quotes_gpc was a bad idea.

I do have a bit of an issue with what you say in this paragraph. I may 
be reading stuff into it, though, if so please accept my apologies if 
that's the case:

I think you're saying that taint truly is a vehicle to enforce some 
level security. But I think we both know that it's more of a spotty 

In other words, I've always held taint to be a potentially useful tool 
akin to sort of run-time linter, rather anything that anyone would allow 
to fire in production code. Sure. You want your code to rather blow up 
than not in those circumstances, but you can't rely on its correctness 
100% of all cases and all non-contrived code that is correct with taint 
is also correct without.

This being said, I have no intentions to take the feature away from 
anyone except my co-workers. I happen to think it's rather useless in 
practical terms, but I don't intend to make that choice for others.

> Of course you can test it against a good chunk of CPAN at your scale.
> But that is only after either selecting the modules that don't use taint
> mode (fortunately, most of it don't) or patching the dists that do use
> it (mostly in tests I guess). Not everything in the Perl world happens
> in such a controlled environment.

Oh, there's a more nefarious way of dealing with that. Remember there's 
two defines: NO_TAINT_SUPPORT (which makes it fatal) and 
SILENT_NO_TAINT_SUPPORT (which makes it ... not be a thing, silently 
ignoring -t/-T).

With the silent version, it's really only the modules that would RELY on 
taint mode failing (generally logic in tests that would "run this OTHER 
script with -T, expect it to fail") which need patching.

Nothing really seems to do that - except for the code that actually 
tests taint mode itself.

So incidentally, SILENT_NO_TAINT_SUPPORT means CPAN just works since the 
modules don't rely on taint per se.

> Or do you actually still hope to make it gain first class status one day?

I don't. I'm happy with its status as of today. I think it gives maximum 
benefit, appropriate (low) visibility, and minimum maintenance cost.

The reason why the change to be able to define it out needed to land in 
core is that it, while a trivial change, actually touches a fair number 
of places, so maintaining it as a patch or branch would have been overly 

I would also say that if one is in control of one's code and 
infrastructure, and performance[1] is an issue, enabling 
SILENT_NO_TAINT_SUPPORT is an expert option that is valid to use for others.


[1] Bit of context: Performance here is very relative. Compiling out 
taint support is a small win. So nobody will celebrate a couple of 
percent faster runs of some script or lower latency of web requests. But 
if you spend the CPUs of thousands of beefy servers, such a change could 
save significant money because it applies rather universally.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About