Front page | perl.perl5.porters |
Postings from February 2017
> > 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. 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 > -DSILENT_NO_TAINT_SUPPORT, > * 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 implies NO_TAINT_SUPPORT. > * SILENT_NO_TAINT_SUPPORT is the same as NO_TAINT_SUPPORT except it > * silently ignores -t/-T instead of throwing an exception. > * > * DANGER! Using NO_TAINT_SUPPORT or SILENT_NO_TAINT_SUPPORT > * 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 > VincentThread Previous | Thread Next