Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127093
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>
In-Reply-To: <a4ffe80f-95cb-4656-b167-73fd48151cae@app.fastmail.com>
Date: Fri, 11 Apr 2025 11:14:00 +0800
Message-ID: <CAObMQFeS0Hw5QeFyDy4oA_ePS6tyLR0MVM1K2mGOo=EON6NysA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Change default for
 zend.exception_ignore_args INI setting
To: Larry Garfield <larry@garfieldtech.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)

> > Full agreement with Tim here - make PHP friendly to development.

Generally I do agree with this sentiment. Languages should be
developer-friendly, but not at the expense of safety.

Developers are able to configure an INI setting in multiple ways
including modifying an ini file, using the `ini_set()` method, and
SAPI configuration. We cannot assume that every installation of every
PHP webapp out there is managed by someone who knows, and understands,
the risks of every INI setting.

> > There are only few places where secrets would be actually relevant, and
> > those can be covered by #[SensitiveParameter].
> I tend to agree as well.  #[SensitiveParameter] is the better solution in=
 the 95% case.  If there are libraries still not using it (as the RFC sugge=
sts), those should have bugs (or preferably patches) filed against them.
>
> The great thing about attributes is they're intrinsically backward compat=
ible, so there's no meaningful cost to adding/patching liberally.

While I agree that #[SensitiveParameter] is a nice idea, I believe
it=E2=80=99s currently insufficient in both implementation and adoption to =
be
relied on as the primary means of protecting sensitive data.

Firstly it isn't only a few places where secrets are relevant. People
have different views of what should be considered Sensitive. For
example, under EU regulations anything which contains any Personally
Identifiable Information (PII) should be considered sensitive, that
includes first and last name, e-mail address, phone number, IP
address, and so on. As developers we may not agree, but a stack trace
which was displayed and included some of this information technically
needs to be declared to the data commissioner in the EU within 72
hours (https://www.edps.europa.eu/data-protection/our-role-supervisor/perso=
nal-data-breach_en).

Secondly you cannot apply the #[SensitiveParameter] attribute to
object properties. If you have an object which contains any passwords
or PII, then you have to declare anywhere that you receive that object
in a parameter with the #[SensitiveParameter] attribute. In many
projects that is a huge number of methods - for example anywhere you
format a string _might_ be passed a string which contains PII and
therefore that would arguably need to have the attribute. In the case
of libraries like Guzzle where any Request may contain a credential
then the entire Request object must be declared sensitive at every
usage.

Thirdly, if you pass additional parameters to a function/method there
is no way to apply this attribute (https://3v4l.org/8lBso#v8.4.6). I'm
sure there is still plenty of code out there which makes use of
`func_get_args()` instead of variadic arguments. There are still
libraries out there which insist on supporting ancient versions of PHP
which don't support variadic arguments so there is no way to set these
as Sensitive. Even massive and well-supported libraries like the
AWS-SDK still use `func_get_args()` in places like their
TokenProvider.

While you're correct that it is backwards compatible (and I agree that
this is a fantastic feature of attributes), it is not widely used.
Taking a look at some of the most popular libraries around, many don't
have a single instance of it when arguably they will be passing around
lots of sensitive information, for example:
- aws-sdk-php only uses the SensitiveParameter in unit tests but it
accepts credentials in a variety of places
- Monolog has no uses of it, but is almost certainly going to be
passed around PII, Tokens, Session IDs, etc.
- Guzzle has no uses of it, but again it will almost certainly be
passed credentials, tokens, etc. (e.g. for authentication)

These are all widely used, well-maintained projects, and yet offer
none of the apparent protection from the attribute.

While the attribute is backwards compatible, the process of
identifying appropriate usage and contributing patches can carry a
non-trivial cost to identify possible uses, create a patch, and go
through any pull request review processes. Different groups have
different views on what should be considered Sensitive, so it is also
likely to get caught up in any reviews for discussion.