Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78859
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain pascal-martin.fr designates 176.31.99.170 as permitted sender)
Message-ID: <545FE946.2070804@pascal-martin.fr>
Date: Sun, 09 Nov 2014 23:23:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <5457EF60.1020103@sugarcrm.com>
In-Reply-To: <5457EF60.1020103@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [VOTE] Filtered unserialize()
From: mailing@pascal-martin.fr ("Pascal Martin, AFUP")

On 03/11/2014 22:10, Stas Malyshev wrote:
> I'd like to put to vote my proposal about the filtered unserialize():

Hi,

After discussing this RFC with a few other people, we seem to agree that 
allowing some level of security-related filtering when unserializing is 
a nice idea -- so, we would be +1 on the principle.

Some of us think raising a notice -- or, better, throwing an exception 
-- in case of a not-allowed class might be helpful, especially when it 
comes to detecting problems and unsafe input data. Still, we understand 
__PHP_Incomplete_Class must have been chosen to remain close to the way 
unserialize() now behaves.

-- 
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/