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
duester...@woltlab.com
www.woltlab.com
Managing director:
Marcel Werk
AG Potsdam HRB 26795 P
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php