Re: RFC [Discussion]: Make unserialize() emit a warning for trailing bytes

Am 28.03.2023 um 00:22 schrieb Larry Garfield <larry@garfieldtech.com>: > On Mon, Mar 27, 2023, at 2:12 PM, Mel Dafert wrote: >> On 27 March 2023 20:20:58 CEST, "Michał Marcin Brzuchalski" >> <michal.brzuchalski@gmail.com> wrote: >>> Personally, I'd like the unserialize to throw an exception if trailing bytes are >>> detected. >>> If not by default then with the use of the option passed to unserialize function. >> >> If that's the desired direction, it makes more sense to emit a >> deprecation notice now and throw an exception starting in 9.0. > > I would also favor throwing an exception. This is a security vector being closed, and that > should be closed *hard*. Warnings tend to show up where they're not useful (dev) and get not > noticed where they are (prod). Go all the way to an exception here. I'm not sure why you say this because our set up is the opposite: On dev the warnings are on screen (and could potentially be missed), on production they generate an alert so they are much harder to miss. That's a set up I would recommend, it has worked well for us in maintaining quite an old code base while migrating it to the current PHP version. > I'm flexible on if that happens in 8.3 or 9. Maybe warning now, with exception in 9? I > don't know if that's better from a BC POV, but it should end up as an exception. I'm generally in favor of going through a warning phase before switching to an exception but if the people here consider this a real security issue I wouldn't rally against an exception. Regards, - Chris