Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98834
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.171 as permitted sender)
MIME-Version: 1.0
Date: Fri, 21 Apr 2017 11:38:47 +0200
Message-ID: <CAF+90c9qDhDE30F+5ZFVEJYe_sC63Bf4ooQTbKBf455z2fDdRA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1141c2da395ce1054daa06ad
Subject: A replacement for the Serializable interface
From: nikita.ppv@gmail.com (Nikita Popov)

--001a1141c2da395ce1054daa06ad
Content-Type: text/plain; charset=UTF-8

Hi internals,

As you are surely aware, serialization in PHP is a big mess. Said mess is
caused by some fundamental issues in the serialization format, and
exacerbated by the existence of the Serializable interface. Fixing the
serialization format is likely not possible at this point, but we can
replace Serializable with a better alternative and I'd like to start a
discussion on that.

The problem is essentially that Serializable::serialize() is expected to
return a string, which is generally obtained by recursively calling
serialize() in the Serializable::serialize() implementation. This
serialize() call shares state information with the outer serialize(), to
ensure that two references to the same object (or the same reference) will
continue referring to a single object/reference after serialization.

This causes two big issues:

First, the implementation is highly order-dependent. If
Serializable::serialize() contains multiple calls to serialize(), then
calls to unserialize() have to be repeated **in the same order** in
Serializable::unserialize(), otherwise unserialization may fail or be
corrupted. In particular this means that using parent::serialize() and
parent::unserialize() is unsafe. (See also
https://bugs.php.net/bug.php?id=66052 and linked bugs.)

Second, the existence of Serializable introduces security issues that we
cannot fix. Allowing the execution of PHP code during unserialization is
unsafe, and even innocuous looking code is easily exploited. We have
recently mitigated __wakeup() based attacks by delaying __wakeup() calls
until the end of the unserialization. We cannot do the same for
Serializable::unserialize() calls, as their design strictly requires the
unserialization context to still be active during the call. Similarly,
Serializable prevents an up-front validation pass of the serialized string,
as the format used for Serializable objects is user-defined.

The delayed __wakeup() mitigation mentioned in the previous point also
interacts badly with Serializable, because we have to delay __wakeup()
calls to the end of the unserialization, which in particular also implies
that Serializable::unserialize() sees objects prior to wakeup. (See also
https://bugs.php.net/bug.php?id=74436.)

In the end, everything comes down to the fact that Serializable requires
nested serialization calls with context sharing.

The alternative mechanism (__sleep + __wakeup) does not have these issues
(anymore), but it is not sufficiently flexible for general use: Notably,
__sleep() allows you to limit which properties are serialized, but the
properties still have to actually exist on the object.

I'd like to propose the addition of a new mechanism which essentially works
the same way as Serializable, but uses arrays instead of strings and does
not share context. I'm not sure about the naming (RealSerializable,
anyone?), so I'll just go with magic methods __serialize() and
__unserialize() for now:

    public function __serialize() : array;
    public function __unserialize(array $data) : void;

From a userland perspective the implementation should be the same as for
Serializable methods, but with interior serialize()/unserialize() calls
stripped out. Right now Serializable implementations already usually work
by doing something like "return serialize([ ... ])", this would change it
to just "return [ ... ]" and move the serialize()/unserialize() call into
the engine, where we can perform it safely and robustly.

The new methods should reuse the "O" serialization format, rather than
introducing a new one. This allows a measure of interoperability with
previous PHP versions, which can still decode serialized strings from newer
versions using __wakeup().

If an object has both __wakeup() and __unserialize(), then __unserialize()
should be called. If an object implements both Serializable::unserialize()
and __unserialize(), then we should invoke one or the other based on
whether "C" or "O" serialization is used.

Thoughts?

Nikita

--001a1141c2da395ce1054daa06ad--