On Mon, Jan 10, 2022 at 3:05 PM Tim Düsterhus, WoltLab GmbH < duester...@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 Heya, thanks for this RFC! The product I work on provides integration with dozens, if not hundreds of remote services. This can be anything from mailboxes, (S)FTP(S), HTTP, and we have a lot of databases for our tenants. Being the legacy code it is, it's a never ending battle to not expose critical information to the end user. Even though I've been working here for several years now, I still keep finding these things occasionally. As we also use external logging tools (such as the ELK stack), we want as little critical information sent anywhere and this RFC seems to really help reduce the leaking of this information here. In the ideal scenario the connection information minus the password is logged explicitly, so that I have the information available whenever one of the many tenants systems failed to connect to one of the many dynamically configured APIs, but doing this retroactively through millions of lines of code that's over 10 years old is a lot of work. One possible addition; would it be possible to analyze the masked values and mask any 100% matches elsewhere? https://3v4l.org/G0RaQ ``` function one(string $param) { throw new Exception($param); } function two(#[SensitiveParameter] string $param) { one($param); } two('the secret'); Fatal error: Uncaught Exception: the secret in /in/G0RaQ:4 Stack trace: #0 /in/G0RaQ(8): one('the secret') #1 /in/G0RaQ(11): two('the secret') #2 {main} thrown in /in/G0RaQ on line 4 ``` This would help in the scenario where the function `one` comes from an external library, but it also means that I don't have to go through every single layer and add the attributes. In the above example I want any mention of `the secret` to be hidden. Let's say the sensitive data is a password, then I don't want that password shown at all in the stacktrace. The original RFC is already very valuable to me without this, but would still expose a lot of sensitive data I fear. The result I want from this: ``` Fatal error: Uncaught Exception: Object(SensitiveParameter) in /in/G0RaQ:4 Stack trace: #0 /in/G0RaQ(8): one(Object(SensitiveParameter)) #1 /in/G0RaQ(11): two(Object(SensitiveParameter)) #2 {main} thrown in /in/G0RaQ on line 4 ``` This would also cover cases where for some reason the sensitive data is added to the exception. Yes, this big facepalm is something I encounter sadly too often in legacy code.
