Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130377
Precedence: list
MIME-Version: 1.0
References: <939CFA28-A6FF-433F-85A0-B83345CEF4A6@cmpct.info>
 <6c498ed3-3cb0-47a5-a64e-4ad202eba141@bastelstu.be> <CAPhkiZwXXj5opb3ycUL-yK0mhgDjDcFwCu62OiczD1=F9jiXZA@mail.gmail.com>
 <3E4944F8-EDAF-4FBA-89DA-1B22DC39AD8F@cmpct.info>
In-Reply-To: <3E4944F8-EDAF-4FBA-89DA-1B22DC39AD8F@cmpct.info>
Date: Mon, 16 Mar 2026 23:23:42 +0200
Message-ID: <CAPhkiZzDhASK2fyrzWjOL_gYYaY5mi+paL+zXCMWLSjEC1j0pA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Display Function Arguments in Errors
To: Calvin Buckley <calvin@cmpct.info>
Cc: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ee187a064d2ad530"
From: narf@devilix.net (Andrey Andreev)

--000000000000ee187a064d2ad530
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 12, 2026 at 5:59=E2=80=AFPM Calvin Buckley <calvin@cmpct.info> =
wrote:

> On Mar 11, 2026, at 7:06=E2=80=AFPM, Andrey Andreev <narf@devilix.net> wr=
ote:
>
> >
> > 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, no=
t
> realizing the act itself represents a data leak and it is permanent. If
> this is a serious problem without args values being present today, imagin=
e
> 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.
>
> 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.


On one hand, it's true that the cat is already out of the bag. On the
other, that's been the case since at least the days of PHP 4 and related
effort since has been to limit the danger. This would be a first in the
other direction.

Semi-random idea: what if it was a declare statement instead of an INI?
That would have multiple benefits:
- Can limit the exposure to particular scripts rather than globally
- Easy to spot during code reviews and therefore little danger of negligent
leaks
- Potential to consolidate backtraces under the same umbrella and
eventually retire zend.exception_ignore_args

Cheers,
Andrey.

--000000000000ee187a064d2ad530
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">On Thu, Mar 12, 2026 at 5:59=E2=80=AFPM Calvi=
n Buckley &lt;<a href=3D"mailto:calvin@cmpct.info">calvin@cmpct.info</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mar =
11, 2026, at 7:06=E2=80=AFPM, Andrey Andreev &lt;<a href=3D"mailto:narf@dev=
ilix.net" target=3D"_blank">narf@devilix.net</a>&gt; wrote:<br><br>
&gt; <br>
&gt; I want to add one more side-effect that feels discounted: PII and othe=
r sensitive data leaking through logs. Partly what the INI setting is suppo=
sed to address, but IMO it only does so on paper.<br>
&gt; I have dealt with that issue many times, and developers tend to either=
 not take it seriously or propose naive patchwork solutions such as blackli=
sting patterns in already produced logs. Plus, there&#39;s an inherent temp=
tation to temporarily enable such settings for debugging purposes, not real=
izing 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 amp=
lification effect from this addition.<br>
&gt; <br>
&gt; With that being said, I also know the pain of having to deal with bord=
erline useless error messages. The proposal isn&#39;t without merit, but I&=
#39;d look for alternative approaches that don&#39;t create security headac=
hes.<br><br>
This is something I&#39;m also concerned about, but I feel the cat is<br>
already out of the bag with backtraces in exceptions providing the same<br>
parameter information. PHP and the library ecosystem seem to be adopting<br=
>
the sensitive parameter attribute, so my hope is that applications also<br>
start adopting it.</blockquote><div><br></div><div>On one hand, it&#39;s tr=
ue that the cat is already out of the bag. On the other, that&#39;s been th=
e case since at least the days of PHP 4 and related effort since has been t=
o limit the danger. This would be a first in the other direction.</div><div=
><br></div><div>Semi-random idea: what if it was a declare statement instea=
d of an INI? That would have multiple benefits:</div><div>- Can limit the e=
xposure to particular scripts rather than globally</div><div>- Easy to spot=
 during code reviews and therefore little danger of negligent leaks</div><d=
iv>- Potential to consolidate backtraces under the same umbrella and eventu=
ally retire zend.exception_ignore_args</div><br></div><div class=3D"gmail_q=
uote gmail_quote_container">Cheers,</div><div class=3D"gmail_quote gmail_qu=
ote_container">Andrey.</div></div>

--000000000000ee187a064d2ad530--