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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
