Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115443
MIME-Version: 1.0
References: <CAFv4g+HRHrvCOTgpbVfCXj06De1kL+1+RwnGgq6tcyLNAtLfQA@mail.gmail.com>
 <CAFPFaMJs7qvko=tfBsXuwCqMV3VqXL4TjO2aKWWPjrAicZzM9w@mail.gmail.com>
 <CAFv4g+G85cfjykjKRbOwWg+KXctZ1u93Onu5cLh1bNrtQ0=DPg@mail.gmail.com>
 <CA+kxMuQkBevK5k-Khhpo3tFfHXeSrM+-GCOWRoZoKJ8Y=_mV4Q@mail.gmail.com>
 <CAFv4g+E=tfzKEXQP64DPNYgMBVo1NbvWBOD2LZVKwsGkw_d=Vg@mail.gmail.com>
 <CA+kxMuQe3hmNiZe6XzROfPCzASDHBTWk3G7ZrwT3=eSuzGTC4A@mail.gmail.com>
 <CAFv4g+HMTm5PM=mGKcymO1YocoY5BkT3ReOOpViCHPoo_4TOCw@mail.gmail.com> <CA+kxMuQFggCRX1tOyDwe4GxAJaNHxurTqNfdkruG5prnfw7kLw@mail.gmail.com>
In-Reply-To: <CA+kxMuQFggCRX1tOyDwe4GxAJaNHxurTqNfdkruG5prnfw7kLw@mail.gmail.com>
Date: Fri, 16 Jul 2021 18:40:03 +0100
Message-ID: <CAFv4g+H-t=oD3ugZktaxMa_-V72NwtGonLQ4a3BU1WDf3fDKTg@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: "G. P. B." <george.banyard@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008b4f6c05c74114da"
Subject: Re: [PHP-DEV] [RFC] [VOTE] is_literal
From: craig@craigfrancis.co.uk (Craig Francis)

--0000000000008b4f6c05c74114da
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 16 Jul 2021 at 15:50, Dan Ackroyd <Danack@basereality.com> wrote:

> On Mon, 12 Jul 2021 at 19:57, Craig Francis <craig@craigfrancis.co.uk>
> wrote:
>
> > the =E2=80=9Cgo-safe-html=E2=80=9D library authors decided that
> > "the ergonomics of trusting concatenated constants far outweighs the
> security concern".
>
> Go is a quite different programming language to PHP.
>


Go is different, it's limited to running the check at compile time. That's
why I was referencing the =E2=80=9Cgo-safe-html=E2=80=9D library.

PHP is more dynamic, so we don't need to have the same restrictions (we can
allow the developer to concatenate the string, which allows us to support
existing code, rather than relying on the library).



The current JavaScript equivalent ideas for string literals appear to be
> inactive or archived.



As noted in the RFC, it's this one:
https://github.com/tc39/proposal-array-is-template-object

Krzysztof has just confirmed that he=E2=80=99s working on it, and is curren=
tly
getting it through tc39 (specifically updates related to Realms, a way of
executing JavaScript within the context of a new global object, something
PHP does not need to worry about).


The other JavaScript approach for dealing with trusted types
> (https://auth0.com/blog/securing-spa-with-trusted-types/) is even more
> different than this proposal.



While the article shows some React/Angular code, the focus is on Trusted
Types, which works with this concept. It protects unsafe APIs (like
innerHTML), where you can create a policy with methods to check/filter
values (e.g. forcing the use of DOMPurify). The isTemplateObject method
(which checks that a template string was created by the developer) will
work with Trusted Types, so you don't need to rely on filtering
(unreliable/limited).

Craig

--0000000000008b4f6c05c74114da--