Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128657
Precedence: list
MIME-Version: 1.0
References: <CAOWwgpk1Z_bns=Z55TqpYOBXvBGpurMfjTGPSgQ6Uf5QXfLOjg@mail.gmail.com>
 <cddcbba0366184b616e34637b424645e@bastelstu.be>
In-Reply-To: <cddcbba0366184b616e34637b424645e@bastelstu.be>
Date: Mon, 8 Sep 2025 17:32:13 +0200
Message-ID: <CAEKnhAFFgpBSOU+yTAfvY6_ndZwOmKvOKZG=F2+mamqkJPfrrQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Nicolas Grekas <nicolas.grekas+php@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e9c172063e4be47e"
From: bukka@php.net (Jakub Zelenka)

--000000000000e9c172063e4be47e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Sep 8, 2025 at 4:48=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastelstu.be=
> wrote:

> Hi
>
> Am 2025-09-05 17:53, schrieb Nicolas Grekas:
> > Hello internals,
> >
> > Following the discussion that started at
> > https://externals.io/message/128226#128456 I wrote this RFC to
> > formalize
> > our consensus on the topic.
> >
> > TL;DR, this is about converting the deprecation of __sleep and __wakeup
> > to
> > a documentation-based soft deprecation:
> > https://wiki.php.net/rfc/soft-deprecate-sleep-wakeup
>
> Thank you for the RFC. I have some comments:
>
> 1.
>
> I disagree with the phrasing that the RFC passed with a =E2=80=9Cnarrow m=
argin=E2=80=9D.
> While it is technically true, that this is the narrowest margin for
> accepting an RFC, the necessary margins are already biased in favor of
> not accepting an RFC. That the RFC was accepted means that a significant
> majority of voters were in favor of the deprecation. I did not vote,
> since I did not have sufficient time to form an opinion on the RFC, but
> given the knowledge I've gained as part of the discussion I would now
> vote in favor of the RFC.
>
>
I think the point here was that it was close and the RFC itself was
misleading and omitted some important points that would like change the
final result.


> 5.
>
> The serialization mechanism is also a security sensitive part of the
> language, the fewer moving parts there are, the better. Security is part
> of the motivation for me.
>
>
Could you be more specific here? We do not consider issues (crashes and
similar) resulting from unserializing of the serialized string as security
issues because it must not come from the untrusted source (see
https://www.php.net/manual/en/function.unserialize.php ). I don't remember
any security issue in serialize / unserialize since this rule was set.

Kind Regards

Jakub

--000000000000e9c172063e4be47e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><br><div class=3D"gmail_quote gmail_quote_co=
ntainer"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Sep 8, 2025 at 4:48=
=E2=80=AFPM Tim D=C3=BCsterhus &lt;<a href=3D"mailto:tim@bastelstu.be">tim@=
bastelstu.be</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">Hi<br>
<br>
Am 2025-09-05 17:53, schrieb Nicolas Grekas:<br>
&gt; Hello internals,<br>
&gt; <br>
&gt; Following the discussion that started at<br>
&gt; <a href=3D"https://externals.io/message/128226#128456" rel=3D"noreferr=
er" target=3D"_blank">https://externals.io/message/128226#128456</a> I wrot=
e this RFC to <br>
&gt; formalize<br>
&gt; our consensus on the topic.<br>
&gt; <br>
&gt; TL;DR, this is about converting the deprecation of __sleep and __wakeu=
p <br>
&gt; to<br>
&gt; a documentation-based soft deprecation:<br>
&gt; <a href=3D"https://wiki.php.net/rfc/soft-deprecate-sleep-wakeup" rel=
=3D"noreferrer" target=3D"_blank">https://wiki.php.net/rfc/soft-deprecate-s=
leep-wakeup</a><br>
<br>
Thank you for the RFC. I have some comments:<br>
<br>
1.<br>
<br>
I disagree with the phrasing that the RFC passed with a =E2=80=9Cnarrow mar=
gin=E2=80=9D. <br>
While it is technically true, that this is the narrowest margin for <br>
accepting an RFC, the necessary margins are already biased in favor of <br>
not accepting an RFC. That the RFC was accepted means that a significant <b=
r>
majority of voters were in favor of the deprecation. I did not vote, <br>
since I did not have sufficient time to form an opinion on the RFC, but <br=
>
given the knowledge I&#39;ve gained as part of the discussion I would now <=
br>
vote in favor of the RFC.<br>
<br></blockquote><div><br></div><div>I think the point here was that it was=
 close and the RFC itself was misleading and omitted some important points =
that would like change the final result.</div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">
5.<br>
<br>
The serialization mechanism is also a security sensitive part of the <br>
language, the fewer moving parts there are, the better. Security is part <b=
r>
of the motivation for me.<br>
<br></blockquote><div><br></div><div>Could you be more specific here? We do=
 not consider issues (crashes and similar) resulting from unserializing of =
the serialized string as security issues because it must not come from the =
untrusted source (see <a href=3D"https://www.php.net/manual/en/function.uns=
erialize.php">https://www.php.net/manual/en/function.unserialize.php</a> ).=
 I don&#39;t remember any security issue in serialize / unserialize since t=
his rule was set.</div><div><br></div><div>Kind Regards</div><div><br></div=
><div>Jakub</div></div></div>

--000000000000e9c172063e4be47e--