On Tue, 2006-12-19 at 17:35 +0100, Pierre wrote: > Hello, > > On 12/19/06, Wietse Venema <[EMAIL PROTECTED]> wrote: > > Zeev Suraski: > > > Following up on an earlier suggestion in this thread, I could see > > at least three modes of operation: > > > > 1) Disabled. The default setting. > > > > 2) Audit mode. Report perceived problems to logfile. This can be > > used by developers to catch bugs, and by deployers for quality > > assessment (but developers please don't start screaming yet). > > > > 3) Enforcement mode. Don't allow execution past a perceived problem. > > I do not think a taint mode is a good thing however to reject this > need would be a mistake. But there is a huge difference between a > taint mode for the developers or the audit team and something that > _will_ be enabled in many ISP, an enforcement mode. I'm "strongly" > opposed to add this mode.
In a previous post Pierre I suggested to prevent ISPs from thinking this does anything for them that it should be configurable via PHP_INI_ALL. So even if an ISP enabled mode 3, a developer can set it themself right in their source code. Since taint checking is necessarily a run time problem, there's no reason not to allow disabling it via ini_set(). This would ensure that developers would never be put up against the wall of frustration so often encountered by safe mode restrictions. Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
