Re: RFC [Discussion]: Redacting parameters in back traces

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