Hi!
The vote for https://wiki.php.net/rfc/secure_unserialize has been
completed (actually, should be last week but I was busy, sorry for the
delay) and the RFC is accepted 17 votes for to 6 votes against.
Now, there were proposals to amend this RFC slightly to make the
additional parameter an option array - with sole option currently being
accepted classes list for now - in order to allow future extensibility.
I am somewhat undecided on this option, but rather than make a new vote
for a small implementation change, I want to make an informal poll -
if I decide to make it an option array - would anyone strongly oppose
to it, and if so, why?
Note that it is not a vote either way - rather, I'd like to hear if
somebody has an argument against doing this (I've already heard
arguments for it). So if you oppose it, please tell the reasons why. I
have some (which I previously posted on the list) but I'd like to hear
from others too.
Thanks,
Stas
On Tue, Nov 18, 2014 at 9:34 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
The vote for https://wiki.php.net/rfc/secure_unserialize has been
completed (actually, should be last week but I was busy, sorry for the
delay) and the RFC is accepted 17 votes for to 6 votes against.Now, there were proposals to amend this RFC slightly to make the
additional parameter an option array - with sole option currently being
accepted classes list for now - in order to allow future extensibility.
I am somewhat undecided on this option, but rather than make a new vote
for a small implementation change, I want to make an informal poll -
if I decide to make it an option array - would anyone strongly oppose
to it, and if so, why?Note that it is not a vote either way - rather, I'd like to hear if
somebody has an argument against doing this (I've already heard
arguments for it). So if you oppose it, please tell the reasons why. I
have some (which I previously posted on the list) but I'd like to hear
from others too.Thanks,
Stas--
Sorry, I missed this thread back when you posted.
Personally I'm a bit hesitant about this change.
Do we already have something additional/upcoming features which could be a
good fit to lump together with allowed_classes?
If that's not the case, I think this is premature to introduce another
level of indirection, which will cost everybody using this feature a couple
of additional keystrokes for the vague gain that at some point in the
future there could be a feature which would be better bundled together with
this setting instead of introducing a third optional parameter.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
Sorry, I missed this thread back when you posted.
Personally I'm a bit hesitant about this change.
Do we already have something additional/upcoming features which could be
a good fit to lump together with allowed_classes?
There was talk about limiting depth or breadth to prevent hash DoS
attacks, etc. While I myself do not plan to work on it in near future,
after some though I decided it does not hurt to provide this
opportunity. The added benefit is, given no named parameters syntax yet,
this is a good way to introduce people reading the code to the meaning
of the feature - ["allowed_classes" => ...] would be pretty obvious
about what this does.
Stas Malyshev
smalyshev@gmail.com