Doc #76606 [Ver]: Widespread regression with Serializable interface and legacy __wakeup method
| From: | ab@php.net | Date: | Tue, 10 Jul 2018 19:47:50 +0000 |
| Subject: | Doc #76606 [Ver]: Widespread regression with Serializable interface and legacy __wakeup method | ||
| References: | 1 | Groups: | php.doc.bugs |
| Request: | Send a blank email to doc-bugs+get-15871@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=76606&edit=1
ID: 76606
Updated by: ab@php.net
Reported by: westie at typefish dot co dot uk
Summary: Widespread regression with Serializable interface
and legacy __wakeup method
Status: Verified
Type: Documentation Problem
Package: Class/Object related
Operating System: All tested
PHP Version: Irrelevant
Assigned To: ab
Block user comment: N
Private report: N
New Comment:
Thanks for digging that deep, Christoph. The original issue was local but turned out to reveal a
common vulnerability with handling of the internal classe unserialisation. There was fixes on top of
that as well. In the end, the decision of the 5.4, 5.5 and 5.6 RMs was to keep the essential part of
the fix. Please check the links from Ferenc in the ticket you've linked. In the light of the
issues revealed, the sentence "Classes that implement this interface no longer support
__sleep() and __wakeup()." has still the precedence.
@westie sure in some grades it might be painful to migrate an app from 5.4 to 7.x. There has been
much more change than just this one in the meanwhile. The most viable way would be to recreate a
clean serialized data for your app. And, manipulated serialize strings was never promised to work.
In the end, it is a documentation issue today.
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2018-07-10 16:57:48] cmb@php.net
I, personally, would advise against storing long-lasting data in
serialized format, anyway.
Anyhow, Anatol, what do you think? Would it be possible and
sensible to restore the old behavior?
------------------------------------------------------------------------
[2018-07-10 16:44:44] westie at typefish dot co dot uk
I would not call this a documentation issue.
With the exception of say, creating an alternative serialisation parser either in PHP or as a
module, how would one go about using the features of Serializable whilst keeping backwards
compatibility with older serialised data?
I don't seem to recall when implementing JsonSerializable being unable to use serialize()...
------------------------------------------------------------------------
[2018-07-10 16:33:19] cmb@php.net
The behavioral change has been introduced with commit 5328d42[1]
(which fixed bug #67072). Restoring the documented behavior (if
that even will be possible) doesn't appear to make sense after
such a long time, so the documentation needs to be fixed.
[1] <https://github.com/php/php-src/commit/5328d4289946e260232f3195ba2e0f0eb173d5ef>
------------------------------------------------------------------------
[2018-07-10 15:09:21] westie at typefish dot co dot uk
https://3v4l.org/rWFHv
To re-iterate, failing on all normal PHP versions yet working as expected on a third party PHP
implementation (HHVM)
------------------------------------------------------------------------
[2018-07-10 14:28:37] westie at typefish dot co dot uk
Please reverse the 'expected' and 'actual' results, I swapped them around.
To confirm what the expect result should be:
string(48) "(input) O:15:"Test_TestClassA":1:{s:1:"x";i:4;}"
string(8) "__wakeup"
string(23) "(output) true (passing)"
string(48) "(input) O:15:"Test_TestClassB":1:{s:1:"x";i:4;}"
string(8) "__wakeup"
string(23) "(output) true (passing)"
string(49) "(input) O:16:"Test_TestClassAA":1:{s:1:"x";i:4;}"
string(8) "__wakeup"
string(23) "(output) true (passing)"
string(49) "(input) O:16:"Test_TestClassBB":1:{s:1:"x";i:4;}"
string(8) "__wakeup"
string(23) "(output) true (passing)"
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=76606
--
Edit this bug report at https://bugs.php.net/bug.php?id=76606&edit=1