Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115059
MIME-Version: 1.0
References: <CAFv4g+Gv1qQ2Gtx2Qwo0Dx2Cb_gOXJ=rm7rVy+Jo89PmD-3jnA@mail.gmail.com>
In-Reply-To: <CAFv4g+Gv1qQ2Gtx2Qwo0Dx2Cb_gOXJ=rm7rVy+Jo89PmD-3jnA@mail.gmail.com>
Date: Wed, 23 Jun 2021 17:35:16 +0430
Message-ID: <CAEMvS4GRaqMBPn7ocBX-XU3jzrtpe+9uGfYpG10qc_iKZY80UA@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000dd9add05c56e923d"
Subject: Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted
From: hossein.baghayi@gmail.com (Hossein Baghayi)

--000000000000dd9add05c56e923d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,
What about `is_vulnerable`? Its behaviour would be the inverse of
is_literal.
I mean we don't have to avoid the other side of the coin.

On Tue, 22 Jun 2021 at 22:41, Craig Francis <craig@craigfrancis.co.uk>
wrote:

> Hi Internals,
>
> As the name `is_trusted()` seems to be causing contention, I think more
> than the alternative option would. Since we want to get this right, and w=
e
> still have time before the feature freeze, this might be worth re-looking
> at. Particularly if you are one of those unsure about it, read on.
>
>
>
> The name `is_trusted()` was chosen by a community vote over several days.
> While I=E2=80=99m of a similar opinion that "trusted" might be misleading=
 for some
> in the strength of its word, I do not want to simply override 18 of the 2=
1
> people, who I assume read the RFC, asked questions to clarify on the
> mailing list, understood how it works, and have chosen that name.
>
> However, clearly some people missed the vote and its discussion time, and
> some voted but then perhaps wanted clarifying on what the RFC was fully
> about later. If we say that's about five people, then assuming there is a
> larger audience who reads but does not post (as the voting numbers
> indicated) then I'm inclined to guesstimate that maybe that means 3x the
> number of people share those feelings. And with that number it starts to
> feel like maybe we should double-check here.
>
> While a one-word name is always going to be misunderstood by some people,
> we want to be as clear as possible.
>
> The Function:
> - Is a security-based function that prevents Injection Vulnerabilities in
> PHP.
> - Flags strings written by the developer, including when concatenated.
> - Also accepts integer values, which as purely numerical cannot contain
> code/dangerous characters. (Due to technical limitations within PHP, it's
> not possible for these to be flagged as user or developer in the codebase
> itself without performance issues).
>
> (RFC for full breakdown: https://wiki.php.net/rfc/is_literal)
>
> Ideally we want a one-word name that suggests this as best we can - one
> word to be consistent with other `is_*()` functions.
>
> - `is_literal()` was my original placeholder name. However, given that it=
's
> not just literal strings, but also supports concatenation and integers I
> felt it may be misleading with the definition of 'literal' stretched so f=
ar
> it might get confusing, and is why I didn't include my original name for =
it
> in the poll. However, if you feel it would be more accurate my mind isn't
> fixed on it.
>
> - `is_known()` - suggested by Joe, who created the implementation, was on=
e
> of two options in the original vote, and was based on the principle that
> the value be 'known' to the developer to be free from external code and b=
e
> within a 'known' understanding of the values that should be going in it.
>
> - `is_trusted()` - suggested by Moritz and separately by Mike, was the
> second option in the original vote, and was based on the idea that what i=
s
> returned can be 'trusted' to be free from external code.
>
> I suggest that people who are serious in their feelings about this, offer
> the name that they would prefer (including potentially making one
> themselves that fits the RFC content and style mentioned above) so we can
> assess whether the current name needs a second look.
>
> Thanks,
> Craig
>

--000000000000dd9add05c56e923d--