Re: [VOTE] Don't automatically unserialize Phar metadata outside getMetadata()
| From: | tyson andre | 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?