Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130294
Precedence: list
MIME-Version: 1.0
References: <939CFA28-A6FF-433F-85A0-B83345CEF4A6@cmpct.info> <6c498ed3-3cb0-47a5-a64e-4ad202eba141@bastelstu.be>
In-Reply-To: <6c498ed3-3cb0-47a5-a64e-4ad202eba141@bastelstu.be>
Date: Thu, 12 Mar 2026 00:06:43 +0200
Message-ID: <CAPhkiZwXXj5opb3ycUL-yK0mhgDjDcFwCu62OiczD1=F9jiXZA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Display Function Arguments in Errors
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Calvin Buckley <calvin@cmpct.info>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008cbb1b064cc6dac5"
From: narf@devilix.net (Andrey Andreev)

--0000000000008cbb1b064cc6dac5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Mar 11, 2026 at 8:38=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastelstu.b=
e> wrote:

> I believe there is almost never =E2=80=9CNo Impact=E2=80=9D to the ecosys=
tem. In fact
> the RFC partly acknowledges it in the =E2=80=9CBackward Incompatible Chan=
ges=E2=80=9D
> section. Even if the corresponding sub-vote to default to 1 doesn't
> pass, code needs to be prepared for someone to set it to 1 themselves.
> This includes off-the-shelf software (such as WordPress, or Drupal, or
> whatever).
>
> I have the following two suggestions (that follow pretty naturally, but
> are nevertheless an impact that should be spelled out):
>
> a) Custom error handlers (set_error_handlers()) need to be prepared for
> the error message format to change. Even though we don't make any
> guarantees about error messages themselves, the existing format with
> =E2=80=9Cfunction name first=E2=80=9D is reasonably structured for automa=
ted parsing
> (e.g. using a regular expression). This also includes error tracking
> tools that try to group error messages by function or similar.
>
> b) System administrators have one more INI setting to deal with and need
> to make a decision. Previous versions of the RFC template had an
> explicit =E2=80=9CINI setting=E2=80=9D section, but given it's so rare we=
 add new INI
> settings these days, it has been removed from the template. For the few
> that still add one, properly discussing the consequences still is valuabl=
e.


These are all excellent points.

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.

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.

Cheers,
Andrey.

--0000000000008cbb1b064cc6dac5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><br><div class=3D"gmail_quote gmail_quote_co=
ntainer"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 11, 2026 at 8:38=
=E2=80=AFPM Tim D=C3=BCsterhus &lt;<a href=3D"mailto:tim@bastelstu.be">tim@=
bastelstu.be</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">
I believe there is almost never =E2=80=9CNo Impact=E2=80=9D to the ecosyste=
m. In fact <br>
the RFC partly acknowledges it in the =E2=80=9CBackward Incompatible Change=
s=E2=80=9D <br>
section. Even if the corresponding sub-vote to default to 1 doesn&#39;t <br=
>
pass, code needs to be prepared for someone to set it to 1 themselves. <br>
This includes off-the-shelf software (such as WordPress, or Drupal, or <br>
whatever).<br>
<br>
I have the following two suggestions (that follow pretty naturally, but <br=
>
are nevertheless an impact that should be spelled out):<br>
<br>
a) Custom error handlers (set_error_handlers()) need to be prepared for <br=
>
the error message format to change. Even though we don&#39;t make any <br>
guarantees about error messages themselves, the existing format with <br>
=E2=80=9Cfunction name first=E2=80=9D is reasonably structured for automate=
d parsing <br>
(e.g. using a regular expression). This also includes error tracking <br>
tools that try to group error messages by function or similar.<br>
<br>
b) System administrators have one more INI setting to deal with and need <b=
r>
to make a decision. Previous versions of the RFC template had an <br>
explicit =E2=80=9CINI setting=E2=80=9D section, but given it&#39;s so rare =
we add new INI <br>
settings these days, it has been removed from the template. For the few <br=
>
that still add one, properly discussing the consequences still is valuable.=
</blockquote><div><br></div><div>These are all excellent points.</div><div>=
<br></div><div>I want to add one more side-effect that feels discounted: PI=
I and other sensitive data leaking through logs. Partly what the INI settin=
g is supposed to address, but IMO it only does so on paper.</div><div>I hav=
e dealt with that issue many times, and developers tend to either not take =
it seriously or propose naive patchwork solutions such as blacklisting patt=
erns in already produced logs. Plus, there&#39;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.</div><div><br></div><div>With that being said, =
I also know the pain of having to deal with borderline useless error messag=
es. The proposal isn&#39;t without merit, but I&#39;d look for alternative =
approaches that don&#39;t create security headaches.</div><div><br></div><d=
iv>Cheers,</div><div>Andrey.</div></div></div>

--0000000000008cbb1b064cc6dac5--