Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115060
User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578
Mime-Version: 1.0
Message-ID: <03f7955c-69a8-4841-9245-449d7851e207@www.fastmail.com>
In-Reply-To: 
 <CAEMvS4GRaqMBPn7ocBX-XU3jzrtpe+9uGfYpG10qc_iKZY80UA@mail.gmail.com>
References: 
 <CAFv4g+Gv1qQ2Gtx2Qwo0Dx2Cb_gOXJ=rm7rVy+Jo89PmD-3jnA@mail.gmail.com>
 <CAEMvS4GRaqMBPn7ocBX-XU3jzrtpe+9uGfYpG10qc_iKZY80UA@mail.gmail.com>
Date: Wed, 23 Jun 2021 08:37:11 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jun 23, 2021, at 8:05 AM, Hossein Baghayi wrote:
> Hello,
> What about `is_vulnerable`? Its behaviour would be the inverse of
> is_literal.
> I mean we don't have to avoid the other side of the coin.

That has the same core problem as is_trusted.  It's making a claim about the probable security status of a value, which I promise you, you will not get right 100% of the time.  is_literal, is asserting only that the value came from the source code originally, not from user input.  That is something you can assert one way or another and be guaranteed correct.  What the *implications* are for what you can then do with it are an entirely separate, and highly squishy and use-case-specific, question.

I'm still very torn on is_literal; I fear that the people who would benefit from it are the very people that don't use the tools that would leverage it (DBALs et al), and so the net benefit will be small, but misuse of it will make DBALs weaker and less able to handle the highly-dynamic cases that I am used to working with.  I may be convinced of is_literal if the major DBAL authors back it, but I'm still not sure.

I am definitely -1 on is_trusted or any other claim of fit-for-purpose, rather than a claim of origin.  That's guaranteed to be incorrect often enough that it makes things worse rather than better.

--Larry Garfield