Evening all, I've prepared an alternative: https://github.com/php/php-src/pull/4282
Hiding the arguments seems sensible enough, not as a hardcoded default (default behaviour should be retained), but as a documented recommended default for production. I think, this needs to go through the RFC process, as nobody can merge an implementation of this without consensus. Cheers Joe On Mon, 17 Jun 2019 at 20:31, Erik Lundin <e...@coretech.se> wrote: > Encrypting logs could potentially impact performance alot. My opinion is > that core dumps and full stack traces should be disabled by default and > activated only when needed to minimize the risk of data leaks. However, > logging is needed. You need to get information about what went wrong. > > Maybe this should be enabled in steps? > > No stack trace (Default?) > Stack trace with obfuscated argument-data > Full stack trace > /Erik Lundin > > > > 17 juni 2019 kl. 19:45 skrev Mark Randall <mar...@gmail.com>: > > > >> On 17/06/2019 18:10, Erik Lundin wrote: > >> Background: > >> The latest version of PHP seems to handle fatal errors as exceptions > which results in stack traces being logged. Stack traces can potentially > contain sensitive information and should not be logged in a production > environment. > > > > Having access to the full stack trace is, in my opinion, an essential > tool for debugging. > > > > Standard PHP Error reporting should always be disabled on production. > > > > On the other hand, security in layers, and the less information you > hold, the less probability there is of it getting out, or being > catastrophic when you do, so having the option to turn it off wouldn't hurt. > > > > As it happens I was dealing with some issues last month where my first > order exception handler was failing, and logs were being put into > stackdriver where they could potentially have been accessed by those who > don't have direct access to the processes but do have access to logging. > > > > I was wondering at the time if it would be possible to supply a public > key via the PHP.ini and have the outputs encrypted before being written - > as this is how I handle the stack traces in my userland exception logging > database and IMHO would provide best-of-both-worlds. > > > > The benefits of public key vs a symmetric key are that the logs remain > secure even with read access to php.ini. > > > > -- > > Mark Randall > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > >
