Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115405
MIME-Version: 1.0
References: <CAFv4g+HRHrvCOTgpbVfCXj06De1kL+1+RwnGgq6tcyLNAtLfQA@mail.gmail.com>
 <CAFPFaMJs7qvko=tfBsXuwCqMV3VqXL4TjO2aKWWPjrAicZzM9w@mail.gmail.com>
 <CAFv4g+G85cfjykjKRbOwWg+KXctZ1u93Onu5cLh1bNrtQ0=DPg@mail.gmail.com>
 <CA+kxMuQkBevK5k-Khhpo3tFfHXeSrM+-GCOWRoZoKJ8Y=_mV4Q@mail.gmail.com> <CAFv4g+E=tfzKEXQP64DPNYgMBVo1NbvWBOD2LZVKwsGkw_d=Vg@mail.gmail.com>
In-Reply-To: <CAFv4g+E=tfzKEXQP64DPNYgMBVo1NbvWBOD2LZVKwsGkw_d=Vg@mail.gmail.com>
Date: Mon, 12 Jul 2021 14:16:53 +0100
Message-ID: <CA+kxMuQe3hmNiZe6XzROfPCzASDHBTWk3G7ZrwT3=eSuzGTC4A@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: "G. P. B." <george.banyard@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [VOTE] is_literal
From: Danack@basereality.com (Dan Ackroyd)

On Mon, 12 Jul 2021 at 02:09, Craig Francis <craig@craigfrancis.co.uk> wrot=
e:
>
> you can choose not to use string concatenation ... allowing anyone to cus=
tomise it to their needs

Please can you explain how:

i) An individual programmer can enforce that they don't accidentally
use string concatenation for stuff that is used in a security
sensitive context.

ii) A team of 50 programmers can enforce that they don't accidentally
use string concatenation for stuff that is used in a security
sensitive context.

iii) A library can enforce that string concatenation isn't used in the
params passed to it.


> and doesn=E2=80=99t improve security in any way,

It prevents issues from being able to make it through to production.
But the main reason would be to reduce the cost of using this feature
long-term.

> you can choose not to use string concatenation (I haven't needed to).

Wait....what?

Is your position both that preserving literal-ness across string
concatenation is required, otherwise this feature is too hard to use,
and at the same time, you've not needed that in your own applications.

Is that right? Because if preserving literal-ness across strings
wasn't required for you...why would it be required for every other
project?

And to be clear, I don't think it's required.

I think by listening to feedback from people who aren't sure it's a
good idea, who said "this is a good idea but only if it's really easy
to start using it" that this RFC has been watered down from the most
useful proposal. At the core, there is a good idea behind this RFC,
but the set of trade-offs chosen just aren't the right ones, and
aren't the "proven" trade-offs made at Google.

cheers
Dan
Ack