Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106282
MIME-Version: 1.0
References: <CAFPFaMLpZ=okschrpeH77AhZTHcvFBuPf1S1bXH6psxmvABK7g@mail.gmail.com>
 <28a9ccf7-f5be-eb1e-999a-06170beeed4b@gmail.com> <CAF+90c_rm3UcGzV4FhLs_-VzFvnE0Uq0m1e_WO5B5uQ+J8+A5g@mail.gmail.com>
 <b6cb48e4-05f2-d55e-f1d5-95c7efc983e9@gmail.com> <5d37a85f.1c69fb81.9e2eb.29d0SMTPIN_ADDED_MISSING@mx.google.com>
 <182e4bf7-05f0-5dec-0e4d-4071cb1249a8@gmail.com>
In-Reply-To: <182e4bf7-05f0-5dec-0e4d-4071cb1249a8@gmail.com>
Date: Wed, 24 Jul 2019 15:27:19 +0200
Message-ID: <CAFPFaM+8rJkfbjSU_bdWHT4szNaBZtKm0cE8Vu-LaSpck=bUdQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, Zeev Suraski <zeev@php.net>
Content-Type: multipart/alternative; boundary="000000000000963063058e6d4517"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2
From: george.banyard@gmail.com ("G. P. B.")

--000000000000963063058e6d4517
Content-Type: text/plain; charset="UTF-8"

 On Tue, 23 Jul 2019 at 22:22, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > Due to the controversy after the initial vote on the Deprecate PHP's
> Short
> > Open Tag RFC [1] here is a new RFC to deprecate them written with the
> help
> > of Nikita Popov <nikic@php.net>.
>
> Could you please explain what has changed since the last time we
> discussed it that makes it necessary to bring the second RFC on the same
> topic?
>

On Wed, 24 Jul 2019 at 02:41, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > V2 remedies that by maintaining default INI behaviour, as well as
> > nullifying the possibility of code / data leaks by throwing a compiler
> > exception if <? is encountered (and enabled), thus denying the VM an
> > opportunity to execute a file which contains potentially leaky code.
>
> Oh, I thought it was already agreed upon... I thought the RFC somehow
> modifies upon that. I think parse error for 8.x would be acceptable.
>
> --
> Stas Malyshev
> smalyshev@gmail.com
>

Nothing, this is a courtesy vote as the implementation proposed in this RFC
is the one which would be used to implement the previous RFC even though
it is not the one proposed initially.

Now if we can all agree that this can land without needing to go through
this
whole process I think everybody wins: we all don't need to spend time on
this,
it can be merged as it, the RMs could re-tag Beta 1 (which may will need to
happen because of some problems with the wincache extension from what
I'm seeing) which puts less strain on them IMHO.
Because I'm pretty sure I'm one of the most annoyed to need to go through
this process once again.
Is this going to happen? Probably not so here we are.

On Wed, 24 Jul 2019 at 05:51, <vsuraski@gmail.com> wrote:

> - [Short tags]  You need to purposely turn it on in your own deployment -
> people and companies who use it use it exclusively for internal purposes.
>

This is just plain wrong since PHP 5.4 as it is enabled by default and you
need to actively turn it OFF as which can be seen on https://3v4l.org [1]
as it doesn't use any INI configuration files. Now as stated in the RFC:

> Currently the <? short open tag is controlled by the short_open_tag

ini setting. This ini setting is *enabled* by default (if no ini files is
> used),

but *disabled* in both php.ini-development and php.ini-production.


which is probably why most of us - and most users - think that it needs to
be implicitly enabled.


I've modified the RFC to state the removal of the short_open-tags in PHP
9.0.

Best regards

George P. Banyard

[1] https://3v4l.org/kKDI9

--000000000000963063058e6d4517--