Just to explain this tracking of longs. We can track strings because there's space to do that in GC info which recounted types all have.
Where things aren't recounted there is no usable space on the value to store the literal flag without disabling some internal assumptions about type flags. We have explored this, it wouldn't be an acceptable implementation detail. Cheers Joe On Friday, 18 June 2021, Craig Francis <cr...@craigfrancis.co.uk> wrote: > On Fri, 18 Jun 2021 at 15:47, Bruce Weirdan <weir...@gmail.com> wrote: > > > One would be potential denial of service prevention (e.g. with enormous > > `LIMIT` value where only a limited set of ints was intended. > > [...] > > Here you really *don't* want $allowed_ids to include user input. > > > > > The developer is writing this query to find those IDs and what the > developer asks for is what they get, the values inside that list came from > somewhere else and *that part earlier* is the bit with the unknown > vulnerability that allowed the value in there. I can’t address logical > flaws from the Developer; what you’re describing is a different issue. This > RFC is to help prevent Injection Vulnerabilities, and it can’t be an > Injection Vulnerability because the variable doesn’t contain commands, it’s > only containing values. We cannot create anything entirely ‘safe’ there’s > no such thing as ‘safe code’, and neither I or anyone else can hope to > create a single RFC that can do that. > > If we just use the original is_literal (without integers), the only > difference in your example will be that, when using integers for something > like this, the developer will need to use a Parameterised Query instead > (because we’d only be accepting literal strings) to do the exact same > thing, and get that same outcome. > > > > Overall I think allowing ints in literal concatenation without tainting the > > result as non-literal is a mistake. > > > > To counter this, supporting integers makes adoption easier, and it’s not > causing any security issues. > > I prefer something that more developers/systems will be able to easily use, > especially when updating existing code. > > > > > > BTW, Psalm already distinguishes `literal-int` from `int` > > > > > Psalm is its own engine - it’s looking at the code, not running it, so it’s > not negatively impacting performance. However PHP itself cannot do this, > integers cannot include a flag to state if they came from source code, > because adding would have too much of a performance impact. > > Or to quote Joe directly "We can't really do that, non reference counted > types are stack allocated, ie the zval on either side of a call boundary > are unique." > > We can’t split integers into two groups. It’s accept integers or no > integers at all. And no integers really isn’t feasible for most developers. > > Craig >
