Re: [RFC] [VOTE] Filtered unserialize()
| From: | Patrick ALLAERT | Date: | Wed, 05 Nov 2014 23:10:57 +0000 |
| Subject: | Re: [RFC] [VOTE] Filtered unserialize() | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-78756@lists.php.net to get a copy of this message | ||
2014-11-04 20:48 GMT+01:00 Dmitry Stogov <dmitry@zend.com>:
> I agree with Nikita.
> Adding an extra argument for one particular security related case looks
> weird.
Same opinion here.
Unfortunately, I can't propose something more robust instead, but I
have the feeling that this RFC tries to solve the symptoms of some
deeper problems with a short-term vision only.
What if I want to unserialize an object of class A which has a
reference to class B? Should "B" be part of the filter? And what if B
has, in turn, some other class references?
I'm +1 for addressing the issue that this RFC tries to solve, but not
in the current state.
Regards,
Patrick