Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105446
MIME-Version: 1.0
References: <CAF+90c-dXndgoPr6GfYsY3gudD3wEhL7YVx=pR=5SUjo2_7_WA@mail.gmail.com>
In-Reply-To: <CAF+90c-dXndgoPr6GfYsY3gudD3wEhL7YVx=pR=5SUjo2_7_WA@mail.gmail.com>
Date: Thu, 25 Apr 2019 13:21:09 +0200
Message-ID: <CAFPFaMLKgT8XeQhoDo-+YS6KM=B_wmf4Pqrw6AvWJcuw-TxvKA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Cc: bishop@php.net, Nikita Popov <nikita.ppv@gmail.com>, markyr@gmail.com
Content-Type: multipart/alternative; boundary="0000000000002695c605875907f7"
Subject: Re: [PHP-DEV] Alternative approach to short tags deprecation
From: george.banyard@gmail.com ("G. P. B.")

--0000000000002695c605875907f7
Content-Type: text/plain; charset="UTF-8"

On Thu, 25 Apr 2019 at 09:15, Nikita Popov <nikita.ppv@gmail.com> wrote:

> Hi internals,
>
> As already discussed in the corresponding voting thread, the deprecation of
> short tags as proposed has a high risk of causing inadvertent source code
> leakage. The RFC proposes to change the default of short_open_tag from On
> to Off in PHP 7.4. Any website using short_open_tags without explicitly
> enabling it (relying on the default) will leak source code unless proper
> precautions are taken before switching to PHP 7.4.
>
> Disregarding the question of whether short tags should be removed at all
> (let's keep that question in the other thread), I do think we need to
> reconsider the deprecation approach. In particular, I would like to
> propose:
>

First of all thanks for tackling this as it seems a lot of issues are
arrising *now*
instead of during the discussion/voting phase.

In PHP 7.4:
>  * The default value of short_open_tag remains as is and enabling
> short_open_tag does not generate a deprecation warning (otherwise PHP would
> warn in a default config).
>  * If short_open_tag is enabled: The first use of <? generates a
> deprecation warning. (Potentially every use could throw a deprecation, but
> generally, if <? is used, it's used a lot and this would cause a lot of
> noise in the error log.)
>  * If short_open_tag is disabled: <? is considered normal text.
>

As I said on the PR implementation I am totally okay to leave the current
default
as it is.

In PHP 8.0:
>  * The default value of short_open_tag remains as is and enabling
> short_open_tag does not generate a deprecation warning or error.
>  * If short_open_tag is enabled: Any use of <? generates a compile error.
>  * If short_open_tag is disabled: <? is considered normal text.
>

In my mind I do think that making the default change in PHP 8 would be
better
but what do I know.


> At a later point in time:
>  * The short_open_tag option is removed.
>  * <? is always considered normal text.
>
> The advantage of such an approach would be that no source code leakage
> could occur when switching to PHP 7.4 or PHP 8.0. The disadvantage is that
> we'll only be able to fully remove short tags support at a later point in
> time.
>
> Thoughts?
>
> Regards,
> Nikita
>

I do not mind the timeline to be significantly altered as I said in one of
my emails
during the initial discussion for the RFC.


On Thu, 25 Apr 2019 at 11:27, Bishop Bettini <bishop@php.net> wrote:

> Respecting your proposal, I feel warning those who explicitly enable
> short_open_tag is good, because such usage is now officially deprecated.
> But not warning those who both use <? and accept the default is not ideal:
> they are the users in the trap. They'll keep moving along accepting the
> status quo, potentially unaware that <? is unportable and also that <?
> removal is planned, until "at a later point in time" their code stops
> running and instead starts being output. So, not warning them is just
> delaying the inevitable, is it not?
>
> I'd suggest therefore an amendment to your proposal, targeting 7.4:
> simultaneous usage of <? and the default setting is a compile time error.
> "Use of <? without explicitly setting short_open_tag = On is unsupported.".
> Such code installations will be forced to either (a) update their code to
> <?php or (b) opt-in to the now-officially-deprecated short_open_tag = On
> behavior. Whichever is least painful for them right now (*).
>
> This amendment effectively removes <? from the language as of 8.0, because
> any usage of <? in 8.0 would be a compile time error. We can then, as you
> say at a later point in time, remove the configuration option and token
> parsing of <?. This implementation seems compatible with the intent of the
> RFC, while addressing the exposure-of-code security concern in the near
> term.
>
> bishop


I really like this approach to signal intent in using the short_open_tag
config
As this means people opting in are fully aware of the fact that it is now
deprecated.

On Thu, 25 Apr 2019 at 12:38, Mark Randall <markyr@gmail.com> wrote:

> (Also: Did I miss a vote option which would have made short_open_tags
> always on?)
>

No you didn't, I did not propose this voting choice.

Best regards

George P. Banyard

--0000000000002695c605875907f7--