On 16-06-2021 19:24, Craig Francis wrote: > On Sat, 12 Jun 2021 at 18:00, Craig Francis <cr...@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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
