On 4/1/13 3:18 PM, Stas Malyshev wrote:
Why? Making use of one parameter is orders of magnitude easier than refactoring your whole application to not use serialize() (especially if you need object support).
Under the RFC, unserialize could potentially create __PHP_Incomplete_Class objects (including nested ones), so new handling code would be needed to care for these cases and I wouldn't describe that as a simple fix depending on how the app wants to deal with these cases.
IMO these projects would be better off creating drop-in replacements for (un)serialize that wrap in HMAC to secure the data channel. Trivially done in userland.
The next best thing would be an unserialize that would simply fail if a non-whitelisted class was found.
Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
