Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105965
MIME-Version: 1.0
References: <alpine.LRH.2.21.1906171908350.27190@supernova.coretech.se>
 <20190617174944.09CAC4A005@supernova.coretech.se> <7840F1AA-297A-42E2-A727-62195670D3D0@coretech.se>
In-Reply-To: <7840F1AA-297A-42E2-A727-62195670D3D0@coretech.se>
Date: Mon, 17 Jun 2019 21:04:27 +0200
Message-ID: <CAOwTYAsCDKS0TkhA2MkKD2+Qbwq5BkutN8cYcF4RuiUYnW5nzA@mail.gmail.com>
To: Erik Lundin <erik@coretech.se>
Cc: Mark Randall <markyr@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f19a0e058b89aa8f"
Subject: Re: [PHP-DEV] Re: [PATCH] Add configuration value to enable/disable
 stack tracelogging
From: krakjoe@gmail.com (Joe Watkins)

--000000000000f19a0e058b89aa8f
Content-Type: text/plain; charset="UTF-8"

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 <erik@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 <markyr@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
> >
>

--000000000000f19a0e058b89aa8f--