Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117136 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 46052 invoked from network); 24 Feb 2022 12:51:27 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Feb 2022 12:51:27 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id AC4D3180088 for ; Thu, 24 Feb 2022 06:11:23 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS199118 195.10.208.0/24 X-Spam-Virus: No X-Envelope-From: Received: from mout-b-105.mailbox.org (mout-b-105.mailbox.org [195.10.208.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 24 Feb 2022 06:11:22 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-b-105.mailbox.org (Postfix) with ESMTPS id 4K4FFP29HFz9sl6 for ; Thu, 24 Feb 2022 15:11:21 +0100 (CET) Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=woltlab.com; s=MBO0001; t=1645711879; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=fAFSxHlODV5/hGASsMUJ5i023IlDfdf3kmFMmutmBi8=; b=AyeUfgApe4SJBrW6tx4thCoRzhtD6esaq2Dm1HsbT+KiP/31ypfBAGexD68HZmDB0950xc 5e3gL29dXPNg4BeplW5KyonYbJqNjmg7b5pCN7M2DIRKi0mIIw4rBEgnJ4urEJib6mrjKq XomDZlgMYIJ/lmnJOwDn7vB5Pj4hM8jnoko6rBZSeo+8d0+BWF7DZrwQ90RgSya3tBP7Dx TzIAgWeTzN83Mv899Fil1LxSl3YmE37ZUWKkW5px2LQhqI0rIhNZjKYQ+8Sf2xTrTkNOzH Qh324/s2+vAMgXVqr3aryJl19tuKP6f6d6zaQfDwxr0EU1q7cNZAFZheVColHw== Date: Thu, 24 Feb 2022 15:11:13 +0100 MIME-Version: 1.0 Content-Language: en-US To: PHP internals Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: SensitiveParameterValue serialization behavior From: duesterhus@woltlab.com (=?UTF-8?Q?Tim_D=c3=bcsterhus=2c_WoltLab_GmbH?=) Hi Internals! during code review of the "Redacting parameters in back traces" RFC [1] an issue with the proposed serialization behavior of SensitiveParameterValue objects became apparent that was not noticed before the RFC went into voting: The RFC proposed that serialization was allowed, but without including the inner value in the serialization data: public function __serialize(): array { return []; } As this operation is lossy, it was proposed that unserialization fails and this is what was implemented in the PoC patch: public function __unserialize(array $data): void { throw new \Exception('...'); } The decision to allow serialization was to allow existing error handlers to work without needing to special case SensitiveParameterValue. However it is clearly not useful, if unserialization does not work after all. Any error during unserialization is not recoverable. Please find the thread in the GitHub PR at: https://github.com/php/php-src/pull/7921#discussion_r813743903 As per Ilija Tovilo's suggestion I'm looping in the Internals list as well. 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. 2. Allow unserialization, but poison the unserialized object and disallow calling ->getValue() on it. This would be closer to the original intent of the RFC, but moves the issue just somewhere else: The object would not be usable either way. ------- What would be your preferred option? Feel free to either reply on the list or add to the discussion on GitHub. Thanks! [1] https://wiki.php.net/rfc/redact_parameters_in_back_traces Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331 96784338 duesterhus@woltlab.com www.woltlab.com Managing director: Marcel Werk AG Potsdam HRB 26795 P