Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26996
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.82.229 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=LEN/txN9OuuYiKx7GcocmbDWW01jtquKk0RpVvnt1lgrof/6wuFWDiY4/br5CnfvlAFa4s+Many5U8TXARMlcQSM3aA2iaE2jf38n2QjUzv3XWPoZaD8F9V2bKh97HbafWvk49WEW9Fty3d2JtbEUkhfFV2BO10RhfyUZxcpe1w=
In-Reply-To: <45832B9B.2080109@zend.com>
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>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <8BC86061-CCC5-45C3-8C40-92B06ADBB117@prohost.org>
Cc: Wietse Venema <wietse@porcupine.org>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Date: Fri, 15 Dec 2006 18:17:16 -0500
To: Stanislav Malyshev <stas@zend.com>
Sender: Ilia Alshanetsky <iliaal@gmail.com>
Subject: Re: [PHP-DEV] Run-time taint support proposal
From: ilia@prohost.org (Ilia Alshanetsky)


On 15-Dec-06, at 6:11 PM, Stanislav Malyshev wrote:

>> All it means is extra work for developers with little or no  
>> tangible benefits. I also wonder how taint will work with the  
>> standard remove/add
>
> Security is benefit. Of course, the developers that are sure they  
> write secure code anyway need not be bothered by tainting and can  
> leave it off forever.

So you claim that without taint mode it is not possible to write safe  
PHP code?

>
>> The job of a language is to provide tools, not arbitrary crippling  
>> limitation under the guise of security improvement.
>
> I agree. Tainting is one of such tools, aimed at improving security.

Tainting is a false security it makes you feel secure, when you  
aren't. First its off in production and that's where all the hacks  
appear, it will have holes due to unforeseen function usage, dynamic  
variables, false untainting etc...

>> safe_mode sounded like a really reasonable idea too, I would've  
>> hoped some lessons from past mistakes could be made.
>
> I do not see what exactly you propose to learn from safe mode  
> mistakes - that we should never try to improve PHP security by  
> providing language level tools? I do not see how this can be  
> derived from whatever was wrong with safe mode. It may be that the  
> tainting would not catch but I do not think safe mode problems  
> should prevent us from even trying.

Good luck, I suppose on a base level it is entertaining seeing  
someone bang their head against the wall time and time again.

Ilia Alshanetsky