Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118858
MIME-Version: 1.0
References: <22177032-fe72-c39b-63fe-fa4368a70852@bastelstu.be>
 <CA+kxMuR=371QXKbD_OVRu+oS7=_qPtL1yN93651wmH-vVVzGhw@mail.gmail.com> <96df967d-c5e8-9c56-bc6d-9858e28294fa@bastelstu.be>
In-Reply-To: <96df967d-c5e8-9c56-bc6d-9858e28294fa@bastelstu.be>
Date: Thu, 20 Oct 2022 15:40:59 +0200
Message-ID: <CA+kxMuSMBG54uLGOM7EGFumxoVKNEi-nG_mZ3BnF6y0epJ=MKA@mail.gmail.com>
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Improve unserialize() error handling
From: Danack@basereality.com (Dan Ackroyd)

On Wed, 19 Oct 2022 at 19:11, Tim D=C3=BCsterhus <tim@bastelstu.be> wrote:
>
> While the behavior would in fact change, it would not introduce a
> "security issue" if this what you were hinting at.

No, just that it would break in production, and then have to be fixed
after a live site was already affecting end-users.

> This would just result in an uncaught Exception which should
> be very visible in your error tracking service.

My impression is that most web-servers running PHP don't have those.

For people who run most sites, the first they would know about it is
when end-users started complaining.

cheers
Dan
Ack