Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130296
Content-Type: text/plain;
	charset=utf-8
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Subject: Re: [PHP-DEV] [RFC] Display Function Arguments in Errors
In-Reply-To: <CAPhkiZwXXj5opb3ycUL-yK0mhgDjDcFwCu62OiczD1=F9jiXZA@mail.gmail.com>
Date: Thu, 12 Mar 2026 12:59:13 -0300
Cc: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <3E4944F8-EDAF-4FBA-89DA-1B22DC39AD8F@cmpct.info>
References: <939CFA28-A6FF-433F-85A0-B83345CEF4A6@cmpct.info>
 <6c498ed3-3cb0-47a5-a64e-4ad202eba141@bastelstu.be>
 <CAPhkiZwXXj5opb3ycUL-yK0mhgDjDcFwCu62OiczD1=F9jiXZA@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
From: calvin@cmpct.info (Calvin Buckley)

On Mar 11, 2026, at 7:06=E2=80=AFPM, Andrey Andreev <narf@devilix.net> =
wrote:
>=20
> Hi,
>=20
> On Wed, Mar 11, 2026 at 8:38=E2=80=AFPM Tim D=C3=BCsterhus =
<tim@bastelstu.be> wrote:
> I believe there is almost never =E2=80=9CNo Impact=E2=80=9D to the =
ecosystem. In fact=20
> the RFC partly acknowledges it in the =E2=80=9CBackward Incompatible =
Changes=E2=80=9D=20
> section. Even if the corresponding sub-vote to default to 1 doesn't=20
> pass, code needs to be prepared for someone to set it to 1 themselves.=20=

> This includes off-the-shelf software (such as WordPress, or Drupal, or=20=

> whatever).
>=20
> I have the following two suggestions (that follow pretty naturally, =
but=20
> are nevertheless an impact that should be spelled out):
>=20
> a) Custom error handlers (set_error_handlers()) need to be prepared =
for=20
> the error message format to change. Even though we don't make any=20
> guarantees about error messages themselves, the existing format with=20=

> =E2=80=9Cfunction name first=E2=80=9D is reasonably structured for =
automated parsing=20
> (e.g. using a regular expression). This also includes error tracking=20=

> tools that try to group error messages by function or similar.
>=20
> b) System administrators have one more INI setting to deal with and =
need=20
> to make a decision. Previous versions of the RFC template had an=20
> explicit =E2=80=9CINI setting=E2=80=9D section, but given it's so rare =
we add new INI=20
> settings these days, it has been removed from the template. For the =
few=20
> that still add one, properly discussing the consequences still is =
valuable.
>=20
> These are all excellent points.
>=20
> I want to add one more side-effect that feels discounted: PII and =
other sensitive data leaking through logs. Partly what the INI setting =
is supposed to address, but IMO it only does so on paper.
> I have dealt with that issue many times, and developers tend to either =
not take it seriously or propose naive patchwork solutions such as =
blacklisting patterns in already produced logs. Plus, there's an =
inherent temptation to temporarily enable such settings for debugging =
purposes, not realizing the act itself represents a data leak and it is =
permanent. If this is a serious problem without args values being =
present today, imagine the amplification effect from this addition.
>=20
> With that being said, I also know the pain of having to deal with =
borderline useless error messages. The proposal isn't without merit, but =
I'd look for alternative approaches that don't create security =
headaches.
>=20
> Cheers,
> Andrey.

This is something I'm also concerned about, but I feel the cat is
already out of the bag with backtraces in exceptions providing the same
parameter information. PHP and the library ecosystem seem to be adopting
the sensitive parameter attribute, so my hope is that applications also
start adopting it.=