On Thu, Apr 25, 2019 at 3:16 AM Nikita Popov <nikita....@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: > > 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. > > 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. > > At a later point in time: > * The short_open_tag option is removed. > * <? is always considered normal text. > I voted for 7.4 deprecation to align engine behavior with long-established documentation, and abstained from the 8.0 removal vote because I have no opinion on the timeline. My rationale being that <? usage is a potential trap, and I'd like to see those traps removed from the language, so long as it's in an orderly fashion. 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 (*) The only corner case I see here is for a hosting install that cannot modify their php.ini settings, and simultaneously are reliant on a third-party library that uses <?. That seems unlikely to me, because library authors have long had to deal with <? potentially being disabled and have stopped shipping their library code in that configuration. So the library would have to be quite old, circa 5.4 perhaps, and would likely have other issues upgrading to 7.4. Notwithstanding, the way around this would be local modification of the library to <?php, which given the age of the library, is likely just copy & paste included in the code base.
