Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115006
Message-ID: <BFFD3FBB-721B-491B-ADDB-DE3CA535BB52@koalephant.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6DE60A4A-D59B-4098-9894-5626872800D9"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Tue, 22 Jun 2021 15:58:57 +0700
In-Reply-To: <CAFv4g+ET4YDpygjKqGbAwxt+jkA8kWTeUrmTcR3hbFGEGNgmDg@mail.gmail.com>
Cc: Benjamin Morel <benjamin.morel@gmail.com>,
 Derick Rethans <derick@php.net>,
 PHP Internals <internals@lists.php.net>,
 Yasuo Ohgaki <yohgaki@ohgaki.net>
To: Craig Francis <craig@craigfrancis.co.uk>
References: <CAFv4g+GjXqiZkA2fawt7jHDtDAKjB0rv=Lfbcobu7bn8B=wvpw@mail.gmail.com>
 <CAGa2bXbGv33zHfRpu-hN_wNcNKPpFw_ed1ZRnn96tpDf0ROcLg@mail.gmail.com>
 <0CD1762E-6094-4DEB-B1B5-22CFBDAAFF44@php.net>
 <CAG9XoMQUUYGhA6QL3Se4FNJgydjzX0MAeR_CWr5O1SH8xgypLA@mail.gmail.com>
 <CAFv4g+ET4YDpygjKqGbAwxt+jkA8kWTeUrmTcR3hbFGEGNgmDg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] is_trusted - was is_literal
From: php-lists@koalephant.com (Stephen Reay)

--Apple-Mail=_6DE60A4A-D59B-4098-9894-5626872800D9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 22 Jun 2021, at 06:28, Craig Francis <craig@craigfrancis.co.uk> =
wrote:
>=20
> On Tue, 22 Jun 2021 at 12:18 am, Benjamin Morel =
<benjamin.morel@gmail.com <mailto:benjamin.morel@gmail.com>>
> wrote:
>=20
>> On Tue, 22 Jun 2021 at 01:06, Derick Rethans <derick@php.net> wrote:
>>=20
>>> On 21 June 2021 23:37:56 BST, Yasuo Ohgaki <yohgaki@ohgaki.net> =
wrote:
>>>>=20
>>>> The name "is_trusted" is misleading.
>>>> Literal is nothing but literal.
>>>=20
>>> I agree with this. The name is_trusted is going to be the same =
naming
>>> mistake as "safe mode" was. Developers will put their trust in it =
that it
>>> is 100% guaranteed safe.
>>=20
>>=20
>> FWIW, agreed, too. Trusted is vague and may imply some false sense of
>> security. Literal is literally what it says on the tin.
>>=20
>=20
>=20
> I can follow up properly tomorrow, but by popular request we do =
support
> integers as well (could be seen as stretching the definition of =
=E2=80=9Cliteral=E2=80=9D a
> bit).
>=20
> And we did ask for suggestions last week, which ended up with a vote =
(as I
> couldn=E2=80=99t decide).
>=20
> That said, I=E2=80=99m really glad that the only issue we seem to have =
is the name.
>=20
> Craig

So I just want to make sure I understand the progression on this so far.


It started out with people wanting a way to check that a string was a =
literal string, in code somewhere, and does not come from user input. Ok =
makes sense. The name makes sense too.

Then someone said they wanted to check if an integer was a literal too - =
but because of technical limitations, it now allows any integer, =
regardless of where it came from, to be treated as a literal.

Then because it=E2=80=99s not actually checking for literals, people =
thought the name =E2=80=9Ctrusted=E2=80=9D made more sense?


That nobody thinks =E2=80=9Cany user supplied integer must be surely =
safe=E2=80=9D is kind of hilarious, and sad at the same time.

Knowing that a string is literal would be very helpful. Knowing that the =
string potentially still contains user input, in spite of the one thing =
it claims to do, is not just unhelpful, it makes the entire thing =
useless.


I can=E2=80=99t vote, but this whole thing would be a No from me unless =
it was the original scope - a variable is a literal defined in code =
somewhere. If there are technical limitations with some types, then =
leave them off the list of what it will check.








--Apple-Mail=_6DE60A4A-D59B-4098-9894-5626872800D9--