Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117001
Message-ID: <399b875f-8703-27f4-1b6d-01f78f53e41c@woltlab.com>
Date: Mon, 7 Feb 2022 17:57:37 +0100
MIME-Version: 1.0
Content-Language: en-US
To: Dan Ackroyd <Danack@basereality.com>
Cc: PHP internals <internals@lists.php.net>
References: <ded42b3e-3149-1192-0f86-07715fcb7a3e@woltlab.com>
 <CA+kxMuTVMeqVN1UFwau3eaVgLa2DKRKaErzSdFCKLw9v066mVQ@mail.gmail.com>
 <01c3082c-c69d-7337-64f7-8314ade305a2@woltlab.com>
 <CA+kxMuQnT137FHe5miAmNgv-ED+WeN=WFEkbe-RRXyKn8zzorQ@mail.gmail.com>
In-Reply-To: <CA+kxMuQnT137FHe5miAmNgv-ED+WeN=WFEkbe-RRXyKn8zzorQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces
From: duesterhus@woltlab.com (=?UTF-8?Q?Tim_D=c3=bcsterhus=2c_WoltLab_GmbH?=)

Hi Dan

On 2/7/22 17:36, Dan Ackroyd wrote:
>> So basically all the other languages I researched do not provide
>> arguments within back traces.
> 
> Uh, that kind of suggests that providing arguments at all is a
> mistake, and that removing could be the way to go. I mean other than
> everyone complaining about the BC break.

Personally I wouldn't complain about the BC break per se, but about that 
making debugging harder :-)

> An awkward question; why is this hard-coding of the behaviour
> dependent on a new attribute the correct thing to do?

Reading through the RFC I concede that this is not (yet) explicitly 
spelled out. However the following sentence appears within the 
"Proposal" section:

> To reliably apply this protection for all types of back traces and all types of exception and error handlers, the redaction should happen when collecting the parameter values during back trace generation.

"reliably apply [...] for all [...] error handlers".

I've explained that in more detail in the podcast with Derick 
(https://phpinternals.news/97).

e.g. at the end of 1:05:

> But in any case, this exception handler will miss sensitive information because it needs to basically guess what parameters are sensitive values and which don't.

-

> PHP allows people to set_error_handler() to process errors how they
> like. Conceiveably, allowing users to set a custom function to redact
> data from stack traces would allow users to inspect and redact the
> parameters however they like. Why is adding a special attribute that
> is recognised by the PHP engine itself the right thing to do?

As explained above: Without having a standardized solution, redacting 
those arguments results in guesswork for the exception handler. A 
userland solution (e.g. standardized in PHP FIG) does not cut it, 
because then native functions will not be protected (e.g. ldap_bind).

I have made the following change to the RFC to hopefully make this 
clearer within the introduction:

https://wiki.php.net/rfc/redact_parameters_in_back_traces?do=diff&rev2%5B0%5D=1643972253&rev2%5B1%5D=1644252789&difftype=sidebyside

Please let me know if this is sufficiently clear, or if you'd like to 
see this expanded further.

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