Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115152
MIME-Version: 1.0
References: <CAFv4g+Gv1qQ2Gtx2Qwo0Dx2Cb_gOXJ=rm7rVy+Jo89PmD-3jnA@mail.gmail.com>
 <CAEMvS4GRaqMBPn7ocBX-XU3jzrtpe+9uGfYpG10qc_iKZY80UA@mail.gmail.com>
 <03f7955c-69a8-4841-9245-449d7851e207@www.fastmail.com> <CAFv4g+EaT309KDWz63j3S7n8E58czEWTKUEw9hAvgt7s6R9eKQ@mail.gmail.com>
 <CAKws9z02yCZTb2_mw-5xUO5-QLc4jbOUcBRfJ8nFSNPP1rgO3g@mail.gmail.com>
 <CA+hqhpfUiOMLDZyXTqP+mm9jjG6v+K94Ug7K_zvuuZus_XhOaQ@mail.gmail.com>
 <CAKws9z34nTT0_CXoo4Yq7zO2CZX622has23xmfHbWjfaDrgLqA@mail.gmail.com>
 <CA+hqhpdR=W8nbWy8UBgLtKdvb_KCss5mpzturS67HhqRj4q6BQ@mail.gmail.com>
 <CAKws9z1=6fmCxJWYVfN+xKT+u=_ZTq0m7C0nZPT6LB5scbfpXQ@mail.gmail.com>
 <95D16F2E-E9DD-4964-A0E2-62E1FB0D976B@koalephant.com> <CAKws9z1M6aLMJ+T7KEAYbEu7N3ufFi8Lsqpr4GP6G06+8aG3SQ@mail.gmail.com>
 <4DE5E2EC-26D6-4D2C-95A9-B843B440EE87@koalephant.com> <CAGBsUrfar+bY+4R9Wp=WfTr5r7-Ur0pVDmNYGJTt1nh9AQ3-Zw@mail.gmail.com>
 <26037CB4-4723-4DC5-BD92-BBDC4F548E17@koalephant.com> <24E12B58-7613-4E67-852C-3312F4AE769C@newclarity.net>
 <CAOwTYAtnib3uWToDxHD5xwHPDq755_xYV4Xte+4UBZQcXA+kow@mail.gmail.com>
 <CA+kxMuSdY6w4pUGsZgSe8RntjsXEFoa=kBHqFYg9vwmD4zEJ9w@mail.gmail.com> <CAFv4g+GimufiLQ97fuRu=yg6uhwuf2cY1mh_uEveKWcQ8wddeg@mail.gmail.com>
In-Reply-To: <CAFv4g+GimufiLQ97fuRu=yg6uhwuf2cY1mh_uEveKWcQ8wddeg@mail.gmail.com>
Date: Sat, 26 Jun 2021 13:24:55 +0100
Message-ID: <CA+kxMuRD3zZfuydusXaH7z0WQDq0-uUHD2TV8kvkaNmxXUAixQ@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>, Joe Watkins <krakjoe@php.net>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted
From: Danack@basereality.com (Dan Ackroyd)

On Fri, 25 Jun 2021 at 00:57, Craig Francis <craig@craigfrancis.co.uk> wrote:
>  > Dan Ackroyd wrote:
> > Please can you go into some detail about what you think people are
> > meant to do when they detect a non-literal used where a literal is
> > expected?
>
> By using a simple function, it allows the library to handle
> the situation however it likes.

That's not an answer to the question.

Just saying "you can handle it however you like" skips over the core
problem with RFC, which is that by supporting carrying the literal
flag through string concatenations,

It allows silly mistakes to slip through and make it to production. As
 per https://news-web.php.net/php.internals/114858:

> Assume that both UserPreferences and getInfoPanel code is covered by
> unit tests. The developer who made that change would run the tests,
> see the tests pass and then push their code live. At which point, it
> would cause an error in production, as the string returned would not
> pass the is_literal check.

For is_literal checks, what's going to happen is:

* programmer makes a mistake, that isn't caught by a test.
* programmer deploys site, and entries about non-literal strings start
being written to log files.
* someone then needs to remember to check the log files, and pull out
the appropriate entries, and make a ticket for them to be
investigated.
* someone then needs to pick up that ticket, investigate the cause of
the non-literal string being used, and trace it back to which
module/library is causing it, then update the ticket for someone on
that team to fix it.
* someone on that team needs to have that ticket prioritised before
they start work on it.

> I'd really like anyone who is promoting this RFC to answer the
> question from https://news-web.php.net/php.internals/115010 :

> Why are you prioritising speed of adoption, over reducing the cost of
> using this feature for projects over say the next 5 or 10 years?

It's going to take more time to track down an error than it will be to
start using the feature.

I had planned to use this RFC to prevent XSS attacks, and in the
current implementation I'm going to get a notice of "There's some
userdata in an inappropriate place. Have fun finding it!" because the
information about where that user data is in the HTML will be lost.

It's still bizarre to me that the RFC is proposing something that
allows mistakes to slip through to production.

cheers
Dan
Ack

btw, email or ticketing systems are not an appropriate place to log
this type of problem. They could happen on every page load, and so
generate hundreds of errors per second. As amusing as it is to look
back at the times that I have generated 10,000 error emails per second
in the past, I don't want to repeat that experience.

Also, I'm going to cross-post this, as it's unreasonable to expect
people to read all of the different threads.