On Thu, Aug 8, 2019 at 3:35 PM Zeev Suraski <z...@php.net> wrote: > 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 >> > > > 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.
