Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106465
MIME-Version: 1.0
References: <CAFPFaML19B_RehrUQLEy_oFae-H5r3+BpUGg=GF1js83cJpJqQ@mail.gmail.com>
 <CAEYWF=4cx_i=3rCfFKeBT0Jq0e4=P0PeY2wd6YEwog_VdA1+Dg@mail.gmail.com> <CAJHtznzie34C92y2nTRXxhD99FEW-5hmruVatsrLDHcAKvTccQ@mail.gmail.com>
In-Reply-To: <CAJHtznzie34C92y2nTRXxhD99FEW-5hmruVatsrLDHcAKvTccQ@mail.gmail.com>
Reply-To: bishop@php.net
Date: Thu, 8 Aug 2019 21:46:12 -0400
Message-ID: <CAEYWF=7S2SxzxU+TzRV0Rc7FNMvyZBkAENVTNbZKqrs71Uyijw@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005f18bd058fa558d4"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
From: bishop@php.net (Bishop Bettini)

--0000000000005f18bd058fa558d4
Content-Type: text/plain; charset="UTF-8"

On Thu, Aug 8, 2019 at 3:35 PM Zeev Suraski <zeev@php.net> wrote:

> On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini <bishop@php.net> wrote:
>
>> On Tue, Aug 6, 2019 at 7:34 AM G. P. B. <george.banyard@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
>> >
>
> 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.
>

No, not even close to the same level.

If my web server's misconfigured, (ALL) of my code's exposed. It's trivial
to write a test to prove that my web server is properly serving PHP files.

But if PHP's misconfigured, (all OR some OR none) of my code's exposed. The
only way to decide is to literally check everything. That's why I
highlighted Robert Korulczyk's case study: only a particular code path in a
particular environment had the problem.

The status quo enables deployments to fail insecurely. <? $dbpassword =
"secret"; is a trap waiting to spring. I would rather require ten thousand
people secure their environment by running a script, than risk a single
person exposing their credentials for all to steal.

I challenge everyone who's voted no to consider this balance.

--0000000000005f18bd058fa558d4--