> Am 26.02.2022 um 12:49 schrieb Dan Ackroyd <dan...@basereality.com>:
>
> On Thu, 24 Feb 2022 at 14:11, Tim Düsterhus, WoltLab GmbH
> <duester...@woltlab.com> wrote:
>>
>> I see two possible options to remediate this issue:
>>
>> -------
>>
>> 1. Disallow both serialization and unserialization.
>>
>> This will make the serialization issue very obvious, but will require
>> adjustments to exception handlers that serialize the stack traces.
>
> That sounds the best option. Yes, people who serialize/unserialize
> stack traces will need to take into account the new behaviour, but
> they will need to do that anyway, and it's better for something to
> fail early, when the data is serialized rather than it happen later
> when someone goes to use that data. Programs continuing when they have
> already failed is Bad™.
>
>> Allow unserialization, but poison the unserialized object and
>> disallow calling ->getValue() on it.
>
> That sounds like something to be instantly added to the list of PHP Sadness.
>
>> I theoretically could add an additional public function isPoisoned(): bool
>> as well.
>
> To me, that sounds like a workaround needed by a bad design aka a hack.
>
> Guilliam Xavier wrote:
>> to avoid potentially breaking existing code.
>
> Technically, all existing code will continue to run, as no-one is
> currently using SensitiveParameter and so that code will continue to
> run. When people start using that feature, then yes they will need to
> make sure that any stack serializer is aware of the new feature. But
> that doesn't sound like a huge problem to me.
That is not technically true from what I understand the SensitiveParameter will
be added to core functions in a second step, so this will make them appear in
existing code immediately.
It would also require some iteration across the whole stack trace and all its
parameters to sanitize. Code that would always look the same and have no extra
purpose.
However i cant seem to wrap my head around serialising stack traces with
parameters. Does someone have an open source example of this kind of code?
Still I am for the second option, because SensitiveParameter without a value is
still enough information in an unserialized state.
>
> In general, I think we should only add surprising and awkward apis
> when there is a really strong reason for doing so, not because there
> might be a problem. If it's left as unserializable for now, people
> would have the opportunity for saying why it needs to be relaxed
> later, aka "no is temporary, yes is forever" for features.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
