Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114930
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <CAFv4g+GYwH-nQ8bLGbm=ThARghGUG5hMpw7W5SjMnSPMTom7+g@mail.gmail.com>
Date: Thu, 17 Jun 2021 09:53:38 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <BB224B8B-DD95-4D53-8DD8-593DA92B6A89@newclarity.net>
References: <CAFv4g+F-7F7o6va5wCrojKe+Uysx2Ec3H4yV_mUZYEyNm3MkdQ@mail.gmail.com>
 <CAFv4g+GYwH-nQ8bLGbm=ThARghGUG5hMpw7W5SjMnSPMTom7+g@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Subject: Re: [PHP-DEV] [RFC] is_literal
From: mike@newclarity.net (Mike Schinkel)



> On Jun 16, 2021, at 1:24 PM, Craig Francis <craig@craigfrancis.co.uk> =
wrote:
>=20
> On Sat, 12 Jun 2021 at 18:00, Craig Francis <craig@craigfrancis.co.uk>
> wrote:
>=20
>> I'd like to start the discussion on the is_literal() RFC:
>> https://wiki.php.net/rfc/is_literal
>>=20
>=20
> Hi Internals,
>=20
> Following up on the is_literal() RFC, thanks for the feedback. It =
looks
> like there are only 2 minor open issues - updating the implementation =
to
> allow integers, and what to call the flag/function.
>=20
> Matthew Brown wants to support integer values, simply because so much =
code
> already includes them, and I cannot find a single way that integers =
alone
> can cause issues from an Injection Vulnerability point of view (but if
> anyone can, I absolutely welcome their input). Other variable types =
like
> floats and booleans will still be excluded (because the value you put =
in
> often is not what you get out, e.g. true/TRUE being converted to "1").
>=20
> Which leads us to the name, because "is_literal" may be, uh, too =
literal.
> So can we come up with something better?
>=20
> It needs to be a name that suggests: This variable contains programmer
> defined strings, integers, and interned values (as noticed by Claude =
Pache
> and Rowan Tommins). Ideally staying in the standard convention of
> =E2=80=98is_singleword=E2=80=99.
>=20
> Joe has suggested is_known(), where "we have the concept of known =
strings
> internally", which I like (though might clash with more userland =
functions
> than =E2=80=98is_literal=E2=80=99). Last night I also wondered about =
`is_constrained()`, as
> the value has limited sources. But I'd also welcome more suggestions, =
and
> am happy to set up a poll (thanks Dharman for the strawpoll.com =
suggestion).

"is_trusted()" comes to mind, inspired by Javascript's Trusted Types =
API[1].

That way in the future it could validate other trusted types besides =
just literals and integers when and if an agreement on what should be =
trusted becomes clear=20

Another plus with the semantics is in many cases the library developer =
who used is_trusted() would not need to update their code to support =
these newly trusted types, e.g. literal-string types, "trusted" classes =
with a __ToString() method, etc.

-Mike

[1] https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API