Refcounted* not recounted ... Predictive text on phone ... Cheers Joe
On Friday, 18 June 2021, Joe Watkins <krak...@gmail.com> wrote: > 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 >> >
