Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105964
Content-Type: multipart/alternative;
	boundary=Apple-Mail-301359A1-506C-4BA0-B3A6-22C9C3792F66
Mime-Version: 1.0 (1.0)
In-Reply-To: <20190617174944.09CAC4A005@supernova.coretech.se>
Date: Mon, 17 Jun 2019 20:31:10 +0200
Cc: internals@lists.php.net
Content-Transfer-Encoding: 7bit
Message-ID: <7840F1AA-297A-42E2-A727-62195670D3D0@coretech.se>
References: <alpine.LRH.2.21.1906171908350.27190@supernova.coretech.se> <20190617174944.09CAC4A005@supernova.coretech.se>
To: Mark Randall <markyr@gmail.com>
Subject: Re: [PHP-DEV] Re: [PATCH] Add configuration value to enable/disable stack tracelogging
From: erik@coretech.se (Erik Lundin)

--Apple-Mail-301359A1-506C-4BA0-B3A6-22C9C3792F66
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Encrypting logs could potentially impact performance alot. My opinion is tha=
t core dumps and full stack traces should be disabled by default and activat=
ed only when needed to minimize the risk of data leaks. However, logging is n=
eeded. You need to get information about what went wrong.=20

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 <markyr@gmail.com>:
>=20
>> On 17/06/2019 18:10, Erik Lundin wrote:
>> Background:
>> The latest version of PHP seems to handle fatal errors as exceptions whic=
h results in stack traces being logged. Stack traces can potentially contain=
 sensitive information and should not be logged in a production environment.=

>=20
> Having access to the full stack trace is, in my opinion, an essential tool=
 for debugging.
>=20
> Standard PHP Error reporting should always be disabled on production.
>=20
> On the other hand, security in layers, and the less information you hold, t=
he less probability there is of it getting out, or being catastrophic when y=
ou do, so having the option to turn it off wouldn't hurt.
>=20
> As it happens I was dealing with some issues last month where my first ord=
er exception handler was failing, and logs were being put into stackdriver w=
here they could potentially have been accessed by those who don't have direc=
t access to the processes but do have access to logging.
>=20
> 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 th=
is is how I handle the stack traces in my userland exception logging databas=
e and IMHO would provide best-of-both-worlds.
>=20
> The benefits of public key vs a symmetric key are that the logs remain sec=
ure even with read access to php.ini.
>=20
> --
> Mark Randall
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20

--Apple-Mail-301359A1-506C-4BA0-B3A6-22C9C3792F66--