Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116854
MIME-Version: 1.0
References: <ded42b3e-3149-1192-0f86-07715fcb7a3e@woltlab.com>
In-Reply-To: <ded42b3e-3149-1192-0f86-07715fcb7a3e@woltlab.com>
Date: Mon, 10 Jan 2022 17:01:06 +0000
Message-ID: <CA+kxMuTVMeqVN1UFwau3eaVgLa2DKRKaErzSdFCKLw9v066mVQ@mail.gmail.com>
To: =?UTF-8?Q?Tim_D=C3=BCsterhus=2C_WoltLab_GmbH?= <duesterhus@woltlab.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces
From: Danack@basereality.com (Dan Ackroyd)

Hi Tim,

On Mon, 10 Jan 2022 at 14:05, Tim D=C3=BCsterhus, WoltLab GmbH
<duesterhus@woltlab.com> wrote:
>
> this is a follow-up for my "Pre-RFC" email from last Friday, January, 7th=
.
>
> https://wiki.php.net/rfc/redact_parameters_in_back_traces
>

How do other languages handle this problem? Or how do they avoid it in
the first place?

From the RFC:
> Specifically the back trace collection should be updated to use an object=
 of class
> \SensitiveParameter as the value for all parameters that are marked with =
the
> \SensitiveParameter attribute.

To me....these words are not clear. Does the following sentence say
the same thing?

"When the backtrace is generated, any parameter that has a
'SensitiveParameter' attribute will not have it's value stored in the
backtrace, but instead will be replaced with an SensitiveParameter
object.

If so, the RFC could be updated to be clearer.....if not, then the RFC
should be updated to be clearer.

Also, having parameters replaced with another type doesn't seem
obviously correct. There should probably be some words justifying why
that is the correct thing to do, rather than just replacing any values
with "****REDACTED***" or other simple behaviour.

> On shared web hosting, the customer might not be able to configure it.

My personal opinion is that shared web hosting shouldn't be a thing
that exists in 2022. And definitely shouldn't be used for anything
where secrets need to be maintained. Yeah shared hosts might have a DB
they can connect to, but those credentials should only be usuable from
the shared host to the DB.

cheers
Dan
Ack