Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115155
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> <CA+kxMuRD3zZfuydusXaH7z0WQDq0-uUHD2TV8kvkaNmxXUAixQ@mail.gmail.com>
In-Reply-To: <CA+kxMuRD3zZfuydusXaH7z0WQDq0-uUHD2TV8kvkaNmxXUAixQ@mail.gmail.com>
Date: Sat, 26 Jun 2021 14:45:39 +0200
Message-ID: <CAOwTYAvjNmk0rBHuQz3PcOfTDFAtok4LJja33RotapYBLJc9_Q@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: Craig Francis <craig@craigfrancis.co.uk>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d9c92d05c5aaa21b"
Subject: Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted
From: krakjoe@gmail.com (Joe Watkins)

--000000000000d9c92d05c5aaa21b
Content-Type: text/plain; charset="UTF-8"

Please, stop spamming us with the same comments.

Cheers
Joe

On Sat, 26 Jun 2021 at 14:25, Dan Ackroyd <Danack@basereality.com> wrote:

> 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.
>

--000000000000d9c92d05c5aaa21b--