Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114910
To: internals@lists.php.net
References: <CAFv4g+F-7F7o6va5wCrojKe+Uysx2Ec3H4yV_mUZYEyNm3MkdQ@mail.gmail.com>
 <CAFv4g+GYwH-nQ8bLGbm=ThARghGUG5hMpw7W5SjMnSPMTom7+g@mail.gmail.com>
Message-ID: <e179b4f4-22ae-5dbb-ce9a-28fb909f90b9@gmail.com>
Date: Wed, 16 Jun 2021 22:13:04 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CAFv4g+GYwH-nQ8bLGbm=ThARghGUG5hMpw7W5SjMnSPMTom7+g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: [RFC] is_literal
From: dik.takken@gmail.com (Dik Takken)

On 16-06-2021 19:24, Craig Francis wrote:
> On Sat, 12 Jun 2021 at 18:00, Craig Francis <craig@craigfrancis.co.uk>
> wrote:
> 
>> I'd like to start the discussion on the is_literal() RFC:
>> https://wiki.php.net/rfc/is_literal
>>
> 
> 
> 
> Hi Internals,
> 
> 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.
> 
> 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").

The security concerns that this RFC is addressing arise from data that
an attacker might control, like user input. In that respect I guess
there need not be any difference between types of literals.

Expanding the 'literal' concept to other types than just strings sounds
like a good idea. However, limiting it to just integers sounds a little
arbitrary. If people want to insert a float or boolean into their query
and they are happy with the way those are coerced into strings, why not
allow it?

> Which leads us to the name, because "is_literal" may be, uh, too literal.
> So can we come up with something better?
> 
> 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
> ‘is_singleword’.
> 
> 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 ‘is_literal’). 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).

Throwing in another idea: is_hard_coded().

> I've also updated the RFC Future Scope to note how this could be a
> dedicated type (thanks someniatko, Matthew Brown, and Dik Takken); and I'm
> really impressed to see the addition to Psalm so quickly.
> 
> Craig
>