On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini <bis...@php.net> wrote:

> On Tue, Aug 6, 2019 at 7:34 AM G. P. B. <george.bany...@gmail.com> wrote:
>
> > The voting for the "Deprecate short open tags, again" [1] RFC has begun.
> > It is expected to last two (2) weeks until 2019-08-20.
> >
> > A counter argument to this RFC is available at
> > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
> >
> > Best regards
> >
> > George P. Banyard
> >
> > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
>
> <? is a security risk today, just as much as it was then. Remember in 2007
> when Facebook's source code leaked precisely because of this [1]?
>

Where's the evidence that it was precisely or even remotely because of
this?  Literally all of the PHP code leaks I've come across over the years
had to do with a misconfigured Web server - e.g., load Apache without
properly setting up handling for .php files, or having things like .inc
files not blocked from HTTP access.
As we deprecate short_tags, should we consider deprecating all SAPIs, and
roll our own high-performance Web server into PHP?  That's the only way to
truly do away with the main vector for PHP source code leakage.


>
> Much has been said about this being a "portability" issue. I think that's
> overly specific. The core issue is "fallibility". You can globally
> configure the language to stop recognizing itself as a language. That's
> weird and unexpected. So much so, that no one gives due thought to this,
> and we end up with security disasters.
>

Except these are so uncommon and rare (I'm not aware of a single one, which
doesn't mean there weren't any - but that they're not very common at all),
that perhaps, just perhaps, it's a bit of an exaggeration to present them
as a clear and present danger.

PHP.net has opined, for years, that <? is bad[2].


This is the opinion of the person who wrote this document.  I'm sure many
agree with him - but there's no person named 'PHP.net' that can opine on
things.
That said - if you think people read the manual and are aware that this is
discouraged and act accordingly - it's all the more reason to not care
about this issue.  If they don't, well, then it doesn't mean much that it's
written over there.  I personally don't think too many people read the
manual on PHP's opening tags (I have absolutely no data to back this gut
feeling up - it's just my gut feel).


> It's time to act. So much
> else breaks at the 8.0 boundary, let's do it all at once.


The "we're breaking things so badly anyway, let's break'm some more"
argument has been refuted many times on this list.  First, I don't think
we're breaking anything really badly in PHP 8.  And secondly, this remains
as bad a reason as it's ever been to break stuff.

Breakage is not binary - it accumulates.  The more you have of it - the
more difficult it is to migrate, and the slower is the migration.


> If anyone needs
> to justify the effort, let them say "<? is a security hole".
>

It's a security hole in the exact same level that httpd.conf is a security
hole.  Yes, misconfiguring your Web server can have severe consequences.
Thankfully, it's not nearly that big of a Thing for us to be concerned
about.

Zeev

Reply via email to