Hi Tim, On Tue, Jan 11, 2022 at 4:40 PM Tim Düsterhus, WoltLab GmbH <duester...@woltlab.com> wrote: > > Hi Pierre > > On 1/11/22 4:48 AM, Pierre Joye wrote: > > Also sensitive data goes way beyond arguments, GDPR brings a lot of > > issues here too. Userland packages like monolog provide filters or > > custom output, I think that is where it should be handled. > > I believe that the author of a function is in the best position to > decide whether a specific argument generally holds sensitive data or > not. This avoids every exception handler / logger / … having to check > what function parameters hold sensitive data and scrubbing them, > possibly missing some.
You are fully correct here. My thoughts differ as I think there are better tools to handle this than PHP itself, as well as all other cases where sensitive data may be exposed (a lot more than backtrace, which is handled already using the ini setting). Things like query errors, etc. There is no way we can handle them all and this is really the developer responsibility to handle this data in a safe manner. We do our best at the engine level for critical data from an engine point of view. Application level critical data are the developers responsibility (config, code, etc.). Best, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
