On 19-Dec-06, at 10:35 AM, Wietse Venema wrote:
As for positioning the feature, I don't think the problem is with the name "taint" itself. It was introduced under this name with Perl3 in 1989(*), and later under the same name in Ruby and other programming languages. I am not aware that shortcomings in taint support have ever been implicated as a cause for security vulnerabilities (but I'm always willing to be corrected). That's 17 years of past experience speaking.
Google search seems to be of a differing opinion, but then it has only been around for 10 years ;-)
I do agree that it is important to build support by explaining what taint support does. The primary purpose of the tool is to help catch a common class of programming error: unchecked inputs in shell/sql commands or other sensitive operations. With a pessimistic taint propagation approach, there will unavoidably be false positives; those false positives will have to be reduced to a practical level.
Bottom line is that does not, there are plenty of Perl application supposedly safe from XSS due to tainting while in reality are trivially exploitable via XSS due to the fact validation regex which does the un-tainting of data is sub-par. Your interpretation of how the tool is position seems to be out of touch with reality, I can guarantee you that people will assume that code that works with taining is safe, which could not be further from the truth.
Some expressed concern that the tool would empower me and others to force a particular programming idiom onto developers (you shall code the way I want to). This is unlikely with the simple black-and-white taint support as proposed initally, where untaint is a broad operation that marks data as good for multiple contexts.
Wrong again, different contexts have different validation criteria, unless you consider that tainting in PHP wont work. What's safe to print on screen may not be safe to execute or pass to the database etc...
As long as we don't overreach (try to stop every problem) and oversell (promise it will stop every problem) then we should be fine, if 17 years of past experience can be applied to PHP.
If you base everything on experience there is no need to use PHP period. Stick to predictable C, Fortran, etc... Just because a person is a great train engineer does not make him a great car mechanic.
Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
