Re: Alternative approach to short tags deprecation
| From: | G. P. B. | Date: | Thu, 25 Apr 2019 11:21:09 +0000 |
| Subject: | Re: Alternative approach to short tags deprecation | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-105446@lists.php.net to get a copy of this message | ||
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