Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127097
Precedence: bulk
MIME-Version: 1.0
References: <CAObMQFcUB48LEusdtYNS2hnr_qyKJppC11qfbGxkOkuKQtqmEg@mail.gmail.com>
 <2e02e8bd16ccd8f326a014fa3812da43@bastelstu.be> <AM8P250MB01700E5B84594B83ED5FB56FE2B72@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <a4ffe80f-95cb-4656-b167-73fd48151cae@app.fastmail.com> <CAGBsUrfxCxOWDsa6A_eN1LLb8TtPjjofCbm96LpuoyZ3126FOw@mail.gmail.com>
 <CAObMQFcwXoRUANgyWQeW03PK5jnpq=PCxQ4ezDGahMMD8cG1mQ@mail.gmail.com>
In-Reply-To: <CAObMQFcwXoRUANgyWQeW03PK5jnpq=PCxQ4ezDGahMMD8cG1mQ@mail.gmail.com>
Date: Fri, 11 Apr 2025 12:11:46 +0100
Message-ID: <CAGBsUrdFy4=Z4bjwmbB4vTwpJ96rG8J2h48Cy+UKMB=vdhr0SQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Change default for
 zend.exception_ignore_args INI setting
To: Andrew Lyons <andrew@nicols.co.uk>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tekiela246@gmail.com (Kamil Tekiela)

> In an ideal world they are never revealed to the end user, but
real-world solutions fall short. It's not uncommon for people to have
display_errors enabled for some reason or another. It is also possible
for sites to be misconfigured, or for applications to make mistakes
and accidentally dump stack traces without realising that they may
contain arguments. Not all applications make use of an error handling
framework, and people may enable display_errors without understanding
the ramifications.

Developers and system administrators are able to mess up their INI
settings in whatever way they want. We can't prevent that. It's a much
bigger issue if someone has display_errors set to On in production
environment, and they could also have set the exception_ignore_args to
Off. We can only suggest the default values for the production
environment. In such a case, I'd argue that setting
exception_ignore_args to Off while having display_errors=3DOff isn't a
big problem. The exception is already sensitive information, maybe not
on the level of PII, but it's definitely something that needs to be
securely protected from end users.

>Can you elaborate? Setting it Off by default increases the risk of
accidental information leakage when apps aren=E2=80=99t correctly configure=
d.
That's great for developers, but for production sites that's not a
good idea. There is no way to guarantee that every PHP application is
a perfect, well-configured, system which uses the latest frameworks.
Many of us are dealing with massive legacy codebases.

Accidental leakage isn't a good argument for keeping this setting On
in production. There should be no accidental leakage, and to prevent
that PHP recommends setting display_errors to Off in the production
environment. It is possible that some application messed up so badly
that even with display_errors=3DOff they might still expose stack trace
to the user, but that's a security bug that should already be reported
to the application developers regardless of whether the stack trace
contains arguments or not.

In my opinion, the only valid argument here is whether it's ok for
arguments to be present in the log files. This would only occur due to
an Exception, Error or Warning/Notice being triggered by the code.
Error log files are supposed to be checked regularly, and errors
should be fixed. Thus, it's only in exceptional situations that this
would happen, i.e. yet an undiscovered bug. Log files should be
treated with similar care as the database, with only the
administrators having controlled access. This means that the only
information that should not appear in log files is the same
information one wouldn't expect to find in the database, e.g.
passwords. We have a solution for this now, it's
#[SensitiveParameter]. You do bring up a good point that many
applications still do not use it due to wanting to support older PHP
versions, but keep in mind that exception_ignore_args is only
available as of PHP 7.4, so users of older PHP versions are screwed
either way. Those on PHP 7.4 > 8.2 can use this INI setting as a
substitute for the new attribute.

On the other hand, if an undiscovered bug happens in the production
environment, it is very useful to know exactly under what
circumstances that happened. Having the full arguments or even just a
truncated part in the stack trace in your log files could make finding
the bug much easier. So it's probably even more important to have the
arguments in the production environment than it is in the development.