Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27091
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <D4.84.28369.81AB7854@pb1.pair.com>
Date: Tue, 19 Dec 2006 12:08:41 +0200
To: Ilia Alshanetsky <ilia@prohost.org>
Cc: Stanislav Malyshev <stas@zend.com>,
 PHP internals <internals@lists.php.net>
In-Reply-To: <7FD783B9-68A7-4EC7-B6C3-8DBC44A51597@prohost.org>
References: <20061215201448.B16D8BC1AB@spike.porcupine.org>
 <7AE00699-23C2-4759-A50C-3D94199DA85A@prohost.org>
 <45831090.1000704@zend.com>
 <18A7CF93-7BFD-4764-847D-6C107A62875E@prohost.org>
 <45831A87.6050301@zend.com>
 <EED341E1-CC7E-4573-BF76-1EE50B01C7A1@prohost.org>
 <45832B9B.2080109@zend.com>
 <8BC86061-CCC5-45C3-8C40-92B06ADBB117@prohost.org>
 <45832F71.2080503@zend.com>
 <7C8CB695-3E81-4009-9699-2499DBF7B366@prohost.org>
 <4583375C.5060302@zend.com>
 <2F093E93-7021-4C0F-A391-A99CBF080596@prohost.org>
 <45833C93.4020909@zend.com>
 <87774C2D-1959-459A-B892-F2F6F6A5C676@prohost.org>
 <45835ABE.5040909@zend.com>
 <6526D55D-DC87-40D4-8335-CCB0FA810646@prohost.org>
 <45846491.6020101@zend.com>
 <7FD783B9-68A7-4EC7-B6C3-8DBC44A51597@prohost.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Run-time taint support proposal
From: zeev@zend.com (Zeev Suraski)

At 23:40 16/12/2006, Ilia Alshanetsky wrote:
>>>You're not helping them, just making assumptions about how their
>>>code should work and making them adhere to them.
>>
>>Yes, and this is helping. Every language does that. Saying "you
>>can't make 100% work exactly as I wanted without any effort, so
>>entire thing isn't even worth discussing" is a road nowhere.
>>There's a lot of places it would be helpful, and there's a lot of
>>places it won't - and that's ok.
>
>I am saying that you should not try to outsmart the developer because
>you assume you know best.

Ilia,

Why are we outsmarting developers?  Security bugs are out there, in 
fact in web apps they're pretty much a plague (irregardless of the 
language).  Does it mean that some developers aren't smart and many 
are not properly informed?  Absolutely YES - that's the world we live 
in...  Given that, and the likelihood it'd only get worse (more and 
more people are programming the web with less and less training) - 
whatever we can provide in the direction of creating better apps can help.

My 2c on this piece is that tainting can be a nice helper tool to 
reduce the likelihood of security problems in your code.  Nothing 
more and nothing less.

I too fear the possibility of tainting becoming the new 
safe_mode.  "Outsource your security to PHP, it'll take care of 
it".  But I think there's a way of both designing and pitching 
tainting so that we avoid this false perception.  If we pitch 
tainting as a development-time only tool the points out a certain 
class of security mistakes, and is by no means an invisible magnetic 
shield that actually protects you from them - then I think it can be 
quite useful.

As such, I would consider:
- Saying tainting should not be enabled in production (avoid the 
false sense of security people might have if they turn on tainting in 
production).
- Not necessarily the fastest possible implementation, since it'd be 
used for development purposes only.
- Consider making this a compile time option with significant 
overhead and a big DO NOT ENABLE IN PRODUCTION, so that people have 
an even clearer idea they shouldn't rely on it to find their bugs, 
and that in fact it's just a helper tool, not unlike a strong IDE.

We could possibly even come up with a new name other than tainting so 
that there is not prior perception as to what this feature is 
supposed or not supposed to do.

Zeev