Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115132
MIME-Version: 1.0
References: <CAFv4g+Gv1qQ2Gtx2Qwo0Dx2Cb_gOXJ=rm7rVy+Jo89PmD-3jnA@mail.gmail.com>
 <CAEMvS4GRaqMBPn7ocBX-XU3jzrtpe+9uGfYpG10qc_iKZY80UA@mail.gmail.com>
 <03f7955c-69a8-4841-9245-449d7851e207@www.fastmail.com> <CAFv4g+EaT309KDWz63j3S7n8E58czEWTKUEw9hAvgt7s6R9eKQ@mail.gmail.com>
 <CAKws9z02yCZTb2_mw-5xUO5-QLc4jbOUcBRfJ8nFSNPP1rgO3g@mail.gmail.com>
 <CA+hqhpfUiOMLDZyXTqP+mm9jjG6v+K94Ug7K_zvuuZus_XhOaQ@mail.gmail.com>
 <CAKws9z34nTT0_CXoo4Yq7zO2CZX622has23xmfHbWjfaDrgLqA@mail.gmail.com>
 <CA+hqhpdR=W8nbWy8UBgLtKdvb_KCss5mpzturS67HhqRj4q6BQ@mail.gmail.com>
 <CAKws9z1=6fmCxJWYVfN+xKT+u=_ZTq0m7C0nZPT6LB5scbfpXQ@mail.gmail.com>
 <95D16F2E-E9DD-4964-A0E2-62E1FB0D976B@koalephant.com> <CAKws9z1M6aLMJ+T7KEAYbEu7N3ufFi8Lsqpr4GP6G06+8aG3SQ@mail.gmail.com>
 <4DE5E2EC-26D6-4D2C-95A9-B843B440EE87@koalephant.com> <CAGBsUrfar+bY+4R9Wp=WfTr5r7-Ur0pVDmNYGJTt1nh9AQ3-Zw@mail.gmail.com>
 <26037CB4-4723-4DC5-BD92-BBDC4F548E17@koalephant.com> <24E12B58-7613-4E67-852C-3312F4AE769C@newclarity.net>
 <CAOwTYAtnib3uWToDxHD5xwHPDq755_xYV4Xte+4UBZQcXA+kow@mail.gmail.com>
In-Reply-To: <CAOwTYAtnib3uWToDxHD5xwHPDq755_xYV4Xte+4UBZQcXA+kow@mail.gmail.com>
Date: Thu, 24 Jun 2021 21:25:25 +0100
Message-ID: <CA+kxMuSdY6w4pUGsZgSe8RntjsXEFoa=kBHqFYg9vwmD4zEJ9w@mail.gmail.com>
To: Joe Watkins <krakjoe@gmail.com>, Craig Francis <craig@craigfrancis.co.uk>
Cc: Stephen Reay <php-lists@koalephant.com>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted
From: Danack@basereality.com (Dan Ackroyd)

On Thu, 24 Jun 2021 at 19:12, Joe Watkins <krakjoe@gmail.com> wrote:
>
> we're not
> talking about a function that protects you from all possible security
> concerns or bugs.

I know. We're talking about something that is meant to protect
programmers against silly mistakes.

And this RFC doesn't do that.

It allows silly mistakes to slip through and make it to production. As
per https://news-web.php.net/php.internals/114858:

> Assume that both UserPreferences and getInfoPanel code is covered by
> unit tests. The developer who made that change would run the tests,
> see the tests pass and then push their code live. At which point, it
> would cause an error in production, as the string returned would not
> pass the is_literal check.

I'd really like anyone who is promoting this RFC to answer the
question from https://news-web.php.net/php.internals/115010 :

> Please can you go into some detail about what you think people are
> meant to do when they detect a non-literal used where a literal is
> expected?

There is a whole load of hand waving going on of "you can protect
yourself!" but then no detail of what this RFC proposes people
actually do, which means people can't evaluate whether it's worth
adding or not.

I know not carrying the literal flag through string concatenation
would make this slightly harder to use. But that would come with lower
long term maintenance, and less mistakes getting through to
production. For security concerns, that seems a good tradeoff to make.

I'd also quite like an answer to the following:

> Why are you prioritising speed of adoption, over reducing the cost of
> using this feature for projects over say the next 5 or 10 years?

I think this feature should be of most value to teams with large
code-bases, where maintaining the code (and figuring out security
problems) has a much higher cost than for small code-bases, where this
feature might not deliver much value. But by carrying the literal flag
through on string concat, that results in it being annoying to use for
teams with large code-bases....which seems self-defeating.

cheers
Dan
Ack