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

Re: Should we consider locked hashes a failed experiment?

Thread Previous | Thread Next
February 2, 2017 17:44
Re: Should we consider locked hashes a failed experiment?
Message ID:

> 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.

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.

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.

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

> As for documentation, we have this in perl.h:
> /* By compiling a perl with -DNO_TAINT_SUPPORT or
>  * you get a perl without taint support, but doubtlessly with a lesser
>  * degree of support. Do not do so unless you know exactly what it means
>  * technically, have a good reason to do so, and know exactly how the
>  * perl will be used. perls with -DSILENT_NO_TAINT_SUPPORT are considered
>  * a potential security risk due to flat out ignoring the security-relevant
>  * taint flags. This being said, a perl without taint support compiled in
>  * has marginal run-time performance benefits.
>  * SILENT_NO_TAINT_SUPPORT is the same as NO_TAINT_SUPPORT except it
>  * silently ignores -t/-T instead of throwing an exception.
>  *
>  *         voids your nonexistent warranty!
>  */
> #
> Which very deliberately overly discourages setting that define to avoid
> traps for the uninitiated. (Last thing we need is some linux distro
> setting that because it seemed a good idea at the time.)
> It also pretty much says what it does. What other docs would you expect
> for something like this?

If it was supported, I'd expect it to find it in POD, and I'm very glad 
that's not the case (which backs my point by the way).

> --Steffen


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