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
From:
Steffen Mueller
Date:
February 2, 2017 21:06
Subject:
Status of NO_TAINT_SUPPORT define (Was: Re: Should we considerlocked hashes a failed experiment?)
Message ID:
c02f5e7e-84bf-a33e-7557-2c8958580d48@steffen-mueller.net
On 02/02/2017 06:38 PM, Vincent Pit (VPIT) wrote:
>
>>
>> No need to be afraid of naming it. It may well be that Booking.com 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).
>>
>> So I concur with Yves, the NO_TAINT_SUPPORT/SILENT_NO_TAINT_SUPPORT
>> 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
heuristic.
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
fragile.
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.
--Steffen
[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