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 >
