Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115455
MIME-Version: 1.0
References: <CAFv4g+HRHrvCOTgpbVfCXj06De1kL+1+RwnGgq6tcyLNAtLfQA@mail.gmail.com>
In-Reply-To: <CAFv4g+HRHrvCOTgpbVfCXj06De1kL+1+RwnGgq6tcyLNAtLfQA@mail.gmail.com>
Date: Sat, 17 Jul 2021 17:05:26 +0200
Message-ID: <CADyq6s+eu4bLM3Z+28Vd0BoGzdbXRyG2Hw9OXqQtyok32p1CJQ@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006c2acc05c753093a"
Subject: Re: [PHP-DEV] [RFC] [VOTE] is_literal
From: ocramius@gmail.com (Marco Pivetta)

--0000000000006c2acc05c753093a
Content-Type: text/plain; charset="UTF-8"

Hey Craig,

On Mon, Jul 5, 2021 at 8:15 PM Craig Francis <craig@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/

--0000000000006c2acc05c753093a--