taint as a first-class feature for php 7.1

Hello again php-internals. I was the original poster of the (most recent) thread on making taint a first-class feature for php. Shortly after the start of the original thread, Laruence ported the existing php-taint extension to php7 (thank you very much sir!). For those of you who might like to try, I have been able to successfully test against php 7.0-rc7 using the following steps: ~~ build php-taint for php7 git clone -b php7 https://github.com/laruence/taint.git php-taint cd php-taint <path to>/phpize ./configure --with-php-config=<path to>/php-config make && make install and to the configuration file <path to php/conf.d>/ext-taint.ini add: [taint] extension=“<path to>//taint.so" taint.enable = On ~~ Recap of discussion so far Administrative: - Any new feature requests should be for php 7.1 and not php 7.0 - Taint should not be written to the logs in the default configuration as is true for NOTICE level logs Pros: - Taint helps to refactor legacy/large code bases - Taint helps to identify entire classes of programming bugs (such as SQL injections) - Security experts suggest taint as a useful tool - Including taint as a first class feature will allow for it to be available in future linux distribution packages of php Cons: - Taint could harm inexperienced or unmindful programmers; improper filtering of a tainted variable could be falsely validated via a taint feature. - Taint may promote inexperienced programers to add bad sanitization, reducing their code quality. ~~ Adding to the discussion Taint is a great feature for identifying where no sanitization is occurring (as opposed to incorrect sanitization). Incorrect sanitization is not addressed by taint and can currently only be addressed via code audit; This situation is analogous to what taint will improve for the ‘no sanitization’ case. Taint will not suggest a contextually correct sanitization, but arming a programmer with the knowledge of where to consider sanitization should at worst promote thought and will at best contribute to improved security globally. The inclusion of taint does not worsen the ‘incorrect sanitization’ case. The inclusion of taint does not hinder future RFCs from addressing the ‘incorrect sanitization’ case. It would be fantastic to be able to call untaint() without having to first check if the module is loaded (as could be the case in a staging versus production environment configuration for example). ~~ Moving forward As discussion seems to have died out, I would like to propose moving to the next stage for inclusion of taint as a first class feature of php 7.1. Kind regards, Christopher Owen.