Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104940
To: "G. P. B." <george.banyard@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAFPFaML1KT2WMhUkZg4rZz3BDV68oPCCufx5+0c26Js--gXj_Q@mail.gmail.com>
Message-ID: <71a54895-13e1-ca9e-1b77-e2d0d64c3d16@cubiclesoft.com>
Date: Mon, 25 Mar 2019 08:45:22 -0700
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120327
 Thunderbird/11.0.1
MIME-Version: 1.0
In-Reply-To: <CAFPFaML1KT2WMhUkZg4rZz3BDV68oPCCufx5+0c26Js--gXj_Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Deprecate PHP's short open tags
From: thruska@cubiclesoft.com (Thomas Hruska)

On 3/25/2019 6:02 AM, G. P. B. wrote:
> Hello internals,
> 
> I would like to start the discussion about the deprecation of PHP's short
> open tags:
> https://wiki.php.net/rfc/deprecate_php_short_tags
> 
> As this is my first RFC all feedback is welcome.
> However, due to the nature of the RFC and it being self-contained, the
> planned date to
> beginning voting this RFC is after the mandatory two weeks discussion
> period and would
> start on Monday the 8th of April (2019-04-08) and be open for two weeks
> until Monday the
> 22nd of April (2019-04-22).
> 
> Best regards
> 
> George P. Banyard

If this moves forward, I, and many others, will demand a formal, fully 
supported utility for locating and automatically transforming all usages 
of short open tags on the system.  That is, a scanner to locate every 
line of code that uses them with options to change the code 
automatically.  (I don't know of anyone who is going to eagerly sift 
through a giant mess of grep output.)  I manage hundreds of *internal* 
software applications that use short open tags.  This proposal, as it 
stands, will *flood* log files with deprecation notices in 7.4 and risks 
exposure of/leaking information like database credentials and various 
secrets like XSRF token bases if someone simply updates to PHP 8 (e.g. 
upgrades the OS, which has a PHP 8 package).  It would be incredibly 
short-sighted to deprecate and remove this but not offer tools to 
developers and deployers to find code that needs to be changed before 
doing the upgrade.

This proposal contains at least one system security issue.  OS package 
managers (apt, yum, etc.) will have to deploy either the aforementioned 
scanner/updater tool and/or look specifically at the relevant existing 
PHP INI setting during upgrade paths and possibly reject the system 
upgrade if it finds even one usage of short open tags on the system.

When I write public, open source software, I always use '<?php' because 
of default INI settings (I'm pretty sure that setting is already Off by 
default in the production INI), but I prefer short open tags in certain 
environments.

However, I'm not necessarily against this proposal.  I just don't think 
all of the ramifications have been thought through.  I also think the 
RFC needs to be updated to mention the various concerns I just mentioned 
under the RFC Impact section.

On a side note, '<?' followed by a whitespace character could just be 
declared an always-on short open tag that doesn't interfere with 
'<?xml'.  That still has some BC breakage but it's less likely to raise 
security-related problems.  That is, it is probably fairly rare to find 
'<?$secret = "supersecretvalue";?>' since important secrets like that 
are generally shunted into a nicely formatted 'settings.php' file. 
However, code like '<?if () ...?> would break but '<? if () ... ?>' 
would not - the latter, IMO, being more readable anyway.  This doesn't 
change the fact that I'd still want a utility to automatically locate 
upgrade issues.

-- 
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/