Re: [VOTE] Don't automatically unserialize Phar metadata outside getMetadata()

From: Date: Wed, 22 Jul 2020 17:25:00 +0000
Subject: Re: [VOTE] Don't automatically unserialize Phar metadata outside getMetadata()
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-111134@lists.php.net to get a copy of this message
Hi internals, > As a minor suggestion: > > > Additionally, add an $allowed_classes parameter to both getMetadata() implementations, > > defaulting to the current behavior of allowing any classes (true). This will be passed to the call > > to unserialize() performed internally. > > Rather than adding an $allowed_classes parameter, I'd add a general $unserialize_options > parameter that just gets passed through to unserialize. E.g.. we also have a "max_depth" > option, which also seems potentially useful. This will ensure that any new limitations we implement > for unserialize() will also be available in this context. I amended https://wiki.php.net/rfc/phar_stop_autoloading_metadata and changed from version 0.3 to 0.4, with the behavior I plan to implement. I'll aim to have the implementation updated by Friday. > 0.4: Change from getMetadata($allowed_classes = …) to getMetadata(array $unserialize_options > = []) in this document. > I forgot about max_depth being added in php 8.0 and the usefulness of being able to support > future options added to unserialize() > without changing the signature of getMetadata. > Elaborate on implementation details $unserialize_options would lead to when setMetaData is > called before > $pharFileOrEntry->getMetadata(['allowed_classes' => $classes]) Any other comments/concerns?

« previous php.internals (#111134) next »