Tomas Kuliavas: > make distclean > ./configure --prefix=/somepath/php \ > --with-config-file-path=/somepath/config/ \ > --with-apxs2=/somepath/apache/bin/apxs \ > --enable-taint \ > --enable-mbstring --disable-mbregex \ > --with-gettext=/usr \ [17 more lines deleted]
OK, I have updated the apache2 module SAPI, and the mbstring extension. I haven't had time to test the other two dozen modules. I've also added a few words of clarification about what to expect with SAPIs and extensions that haven't been updated for taint support, and what to expect when you run an application for the first time with taint support. Fragments of these are below my signature. The updated code is at ftp://ftp.porcupine.org/pub/php/ 6924 Nov 3 21:14 php-5.2.3-taint-20071102-20071103.diff.gz 45718 Nov 3 20:59 php-5.2.3-taint-20071103.README 43662 Nov 3 20:58 php-5.2.3-taint-20071103.README.html 182130 Nov 3 21:18 php-5.2.3-taint-20071103.diff.gz 9381474 Nov 3 21:15 php-5.2.3-taint-20071103.tar.gz (PGP signature files exist, too, but are not shown above). Wietse == README fragment 1 What about the other SAPIs and extensions? The SAPIs need work because some SAPI functions need an extra taint argument, and I could not hide this with macros in some central #include file. The other extensions will work just fine as long as they don't depend on the changed SAPI interface, and as long as you leave taint_error_level at its default setting. They may trigger false warnings when you raise the taint error level, because they don't know how to properly initialize certain bits that taint support relies on. This problem should not exist, but unfortunately there is a lot of PHP source code that does not use standard macros when initializing PHP data structures. Extensions that haven't been updated with taint support will ignore taint information in their inputs, and will therefore not propagate taint information from their inputs to their outputs. == README fragment 2 While testing code for the first time with PHP taint support you will find that you will sometimes need to explicitly mark data as "safe". Usually this happens imediately after successful input validation. if (some expression to make sure $data is safe) { untaint($data); do something with $data; } else { error ... } This is admittedly imperfect: it would be better to specify what context the data is safe for. A proper user interface for this will have to be developed in a future version of PHP taint support. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
