Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127094
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>
In-Reply-To: <CAGBsUrfxCxOWDsa6A_eN1LLb8TtPjjofCbm96LpuoyZ3126FOw@mail.gmail.com>
Date: Fri, 11 Apr 2025 11:15:39 +0800
Message-ID: <CAObMQFcwXoRUANgyWQeW03PK5jnpq=PCxQ4ezDGahMMD8cG1mQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Change default for
 zend.exception_ignore_args INI setting
To: Kamil Tekiela <tekiela246@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: andrew@nicols.co.uk (Andrew Lyons)

> I can't find any information on why this setting was introduced.

No, I couldn't find anything either. I did try to investigate and all
I could find was that it was introduced by Joe Watkins in
0819e6dc9b4788e5d44b64f8e606a56c969a1588 in 2019 but I haven't been
able to find any history of RFC or discussion about it.

> I guess that it was either to protect sensitive information or to reduce
> verbosity in the logs, but either one seems like a poor reason for
> this setting to exist. The INI comment seems to suggest that it was
> introduced to protect sensitive information, but that doesn't make
> sense to me since exceptions aren't revealed to the end user.

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.

Ultimately developers and administrators are all human (for now). We
can, and do, make mistakes. PHP is already capable of preventing
information leakage from such mistakes, but it is currently not the
default configuration. Let's make it the default. This does not stop
people who have actively configured stack trace arguments from having
access to those args.

> And while verbose, arguments in stack traces are useful. On top of that,
> it seems to me like this is already covered by
> exception_string_param_max_len. If you set the length to 0, isn't it
> the same as setting exception_ignore_args to On? Or does that mean
> that no truncation is applied?

Completely off the top of my head, it is probably still worth having
both. A configurable max length isn=E2=80=99t the same as a simple on/off
toggle that can be flipped directly in code.

The max length was actually introduced later by Tyson Andre in
07db64156e180c30daa5ab5d41ed72f9bba77e6d in 2020 and discussed here:
https://externals.io/message/110717

From the look of the commit it _only_ applies to the
`getTraceAsString()` method, and not `getTrace()`. It was intended to
allow more information to be dumped than the previously hard-coded 15
bytes.

Even setting it to 0 doesn=E2=80=99t consistently remove args =E2=80=94 e.g=
.,
getTrace() still includes them, so merging these two is not really a
clear or easy solution.

> I suppose if this INI setting must exist, then it should be set to Off in=
 both development and production environments.

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.

Where a framework correctly configures error handling, and determines
that it needs the arguments as part of that, it is surely able to also
call `ini_set('zend.exception_ignore_args', 0)` at the same time as it
configures that error handler.

> The max length should probably be increased, too. I would also appreciate=
 it if it gets
> clarified in the documentation why the two settings exist and what the
> difference between them is. And I wouldn't object to removing
> exception_ignore_args if it's a redundant setting.

I agree it would be good to clarify this, but I don't think that
either should be removed. Reading the Internals discussion for the
length makes it a little clearer as to why it exists and why they're
separate. I'd suggest that this can be done via PR process without
need for an RFC.

In any case, I would strongly object to removing
`exception_ignore_args`. It is not a redundant setting and it is
critical to many in production.

> P.S. The RFC mentions execution_ignore_args too, but I assume that's a ty=
po.

Thanks - I'll fix that.

On Fri, 11 Apr 2025 at 04:04, Kamil Tekiela <tekiela246@gmail.com> wrote:
>
> I can't find any information on why this setting was introduced. I
> guess that it was either to protect sensitive information or to reduce
> verbosity in the logs, but either one seems like a poor reason for
> this setting to exist. The INI comment seems to suggest that it was
> introduced to protect sensitive information, but that doesn't make
> sense to me since exceptions aren't revealed to the end user. And
> while verbose, arguments in stack traces are useful. On top of that,
> it seems to me like this is already covered by
> exception_string_param_max_len. If you set the length to 0, isn't it
> the same as setting exception_ignore_args to On? Or does that mean
> that no truncation is applied?
>
> I suppose if this INI setting must exist, then it should be set to Off
> in both development and production environments. The max length should
> probably be increased, too. I would also appreciate it if it gets
> clarified in the documentation why the two settings exist and what the
> difference between them is. And I wouldn't object to removing
> exception_ignore_args if it's a redundant setting.
>
> P.S. The RFC mentions execution_ignore_args too, but I assume that's a ty=
po.