Hey Craig, On Mon, Jul 5, 2021 at 8:15 PM Craig Francis <cr...@craigfrancis.co.uk> wrote:
> Hi Internals, > > I have opened voting on https://wiki.php.net/rfc/is_literal for the > is-literal function. > > The vote closes 2021-07-19 > > The proposal is to add the function is_literal(), a simple way to identify > if a string was written by a developer, removing the risk of a variable > containing an Injection Vulnerability. > > This implementation is for literal strings ONLY (after discussion over > allowing integers) and, thanks to the amazing work of Joe Watkins, now > works fully with compiler optimisations, interned strings etc. > > Craig > I ended up voting "no" on this. Even though I used to work on Doctrine ORM for years, and we had a private discussion around this, my belief is that this is not a runtime problem, but rather a type-level issue with tainted/untainted input/output. This has been brought up in the discussion phase by Tyson Andre, as far as I remember. There is good progress in taint analysis in Psalm, specifically: * https://psalm.dev/articles/detect-security-vulnerabilities-with-psalm * https://psalm.dev/docs/security_analysis/ There's also the issue, from my end, that I would like the ecosystem to pick up static analysis more, rather than people adding more runtime roadblocks to their code, leading to further complexity in error analysis. This is my personal push for putting more problems into build-time rather than runtime. You could call it a political choice to push a tool like psalm, instead of the language having a runtime construct to further "duck-type safety". In addition to that, a mechanism to un-taint values is missing, but it is not a concept symmetrical to `is_literal()`. Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
