Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67085 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52187 invoked from network); 15 Apr 2013 13:52:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Apr 2013 13:52:25 -0000 Authentication-Results: pb1.pair.com header.from=thruska@cubiclesoft.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=thruska@cubiclesoft.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain cubiclesoft.com designates 74.208.44.107 as permitted sender) X-PHP-List-Original-Sender: thruska@cubiclesoft.com X-Host-Fingerprint: 74.208.44.107 u15404699.onlinehome-server.com Received: from [74.208.44.107] ([74.208.44.107:54808] helo=u15404699.onlinehome-server.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AB/F1-36222-3160C615 for ; Mon, 15 Apr 2013 09:52:20 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: thruska@cubiclesoft.com) with ESMTPSA id 5869B5001362 Message-ID: <516C0601.7060003@cubiclesoft.com> Date: Mon, 15 Apr 2013 06:52:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: PHP Internals References: <51647536.6030108@sugarcrm.com> <516489F1.70106@lerdorf.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [PROPOSAL] add a leading backslash to classname when serializing/var_exporting From: thruska@cubiclesoft.com (Thomas Hruska) On 4/14/2013 7:56 PM, Laruence wrote: > hey: > thanks very much for all feedbacks. > > so, maybe we should document this instead of adding lead backslash? > > thanks > > > On Wed, Apr 10, 2013 at 5:36 AM, Rasmus Lerdorf wrote: > >> On 04/09/2013 01:23 PM, Madara Uchiha wrote: >>> Well, why would you need to serialize an object in one version of PHP, >>> and unserialize it in another? serialize()/unserialize() is a convenient, clean, and powerful data transport mechanism for PHP across many sessions and hosts. Using serialize() and unserialize() is an addiction - once someone starts, it is impossible for them to stop. json_encode()/json_decode() can be useful for cross-language support, but they are much more limited. json_decode() has the added natural benefit of not being as vulnerable as unserialize(). >> people do that all the time. They store serialized >> versions of stuff in databases and other backends and even send it >> across the wire from one machine to another, so it is quite common for >> something serialized in one version to need to be unserialized in another. >> >> -Rasmus While updating the documentation, maybe also include some discussion on the dangers of unserializing data without first establishing trust? There was a discussion not too long ago on this list about PHP executing __destruct() of unserialized class data from untrusted sources. Example recent exploit: http://packetstormsecurity.com/files/118064/invision_pboard_unserialize_exec.rb.txt -- Thomas Hruska CubicleSoft President I've got great, time saving software that you might find useful. http://cubiclesoft.com/