Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115023
MIME-Version: 1.0
References: <CAFv4g+GjXqiZkA2fawt7jHDtDAKjB0rv=Lfbcobu7bn8B=wvpw@mail.gmail.com>
 <CAGa2bXbGv33zHfRpu-hN_wNcNKPpFw_ed1ZRnn96tpDf0ROcLg@mail.gmail.com>
 <0CD1762E-6094-4DEB-B1B5-22CFBDAAFF44@php.net> <CAG9XoMQUUYGhA6QL3Se4FNJgydjzX0MAeR_CWr5O1SH8xgypLA@mail.gmail.com>
 <CAFv4g+ET4YDpygjKqGbAwxt+jkA8kWTeUrmTcR3hbFGEGNgmDg@mail.gmail.com> <BFFD3FBB-721B-491B-ADDB-DE3CA535BB52@koalephant.com>
In-Reply-To: <BFFD3FBB-721B-491B-ADDB-DE3CA535BB52@koalephant.com>
Date: Tue, 22 Jun 2021 14:13:07 +0100
Message-ID: <CAFv4g+GJrX6uNSAq=kAXDk2Lx=NLx=GxAw9Qh+cpZwbaVdgtJA@mail.gmail.com>
To: Stephen Reay <php-lists@koalephant.com>
Cc: Benjamin Morel <benjamin.morel@gmail.com>, Derick Rethans <derick@php.net>, 
	PHP Internals <internals@lists.php.net>, Yasuo Ohgaki <yohgaki@ohgaki.net>
Content-Type: multipart/alternative; boundary="000000000000ac42e105c55a8d5d"
Subject: Re: [PHP-DEV] [RFC] is_trusted - was is_literal
From: craig@craigfrancis.co.uk (Craig Francis)

--000000000000ac42e105c55a8d5d
Content-Type: text/plain; charset="UTF-8"

On Tue, 22 Jun 2021 at 09:59, Stephen Reay <php-lists@koalephant.com> wrote:

> So I just want to make sure I understand the progression on this so far.
> It started out with people wanting a way to check that a string was a
> literal string, in code somewhere, and does not come from user input. Ok
> makes sense. The name makes sense too.
>



The primary reason was never just to define literal strings, the intention
has always been to create a practical, implementable solution to address
the issue of Injection Vulnerabilities (SQl/HTML/CLI/etc).

The name `is_literal()` has always just been a placeholder, it came up when
I first started looking at this problem because that was the most obvious
thing I knew we could anchor around. (Unfortunately I think it was easy to
make assumptions based solely on that name, rather than focussing on the
issue it is meant to address).

So, we cannot look for literals only - while it was part of the solution,
it was very much incomplete. Bearing in mind, there is considerable amount
of existing code and tutorials out there which include integers in their
SQL/HTML/CLI/etc, and they are perfectly safe in doing so. Making a
solution which does not support integers is not going to be adopted/used
because the task of rewriting and changing everything, for no benefit, will
not be considered by developers.

Likewise, a lot of code already builds SQL/HTML/CLI/etc strings via
concatenation and sprintf(), and forcing everyone to use a query builder is
likely to cause most people to not even consider using this.

It's all well thinking of one thing that might theoretically/idealistically
solve the issue, but it also needs to have a plan on how this will be
practically implemented and used by developers (which this has done).

Craig

--000000000000ac42e105c55a8d5d--