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

From: Date: Tue, 11 Jan 2022 05:37:09 +0000
Subject: Re: RFC [Discussion]: Redacting parameters in back traces
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-116863@lists.php.net to get a copy of this message
On Mon, Jan 10, 2022 at 8:05 AM Tim Düsterhus, WoltLab GmbH < duesterhus@woltlab.com> wrote: > Hi Internals! > > this is a follow-up for my "Pre-RFC" email from last Friday, January, 7th.. > > Christoph Becker granted me RFC editing permissions and I've now written > up our proposal as a proper RFC: > > https://wiki.php.net/rfc/redact_parameters_in_back_traces > > I recommend also taking a look at my previous email: > > https://externals.io/message/116847 > > It contains some additional context that did not really fit within the > language of a "neutral" RFC that will remain as the permanent record. > > - As indicated within the RFC and my previous email we still need a more > experienced developer for the final implementation, as I have next to no > experience with PHP's implementation. > > Specifically adding this attribute to existing functions is not clear to > me. It is probably required to update the stub parser/generator to add > support for attributes? If someone creates an example implementation for > one function, I'll likely be able to apply this to other functions myself.. > - The RFC Impact to Opcache is not clear to me. I don't believe there is > any, but I am not sure. So if someone knows, I'm happy to update that > section. > > > If someone can inject a debug_backtrace into your code and get it executed you have bigger problems than a parameter being exposed. And if you configure your prod servers to be all chatty Kathy to the world on error, you need to learn how to do better. A change to the language is not in order here.

« previous php.internals (#116863) next »