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 > > > > > > 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. > > We need to get rid of the display_errors ini directive as well. It definitely shouldn't default to "1" or be set to "1" in the sample files distributed with PHP. I would think this is a much greater security risk than short tags. While we're at it, we need to get rid of the ability to even set custom error handlers. If a programmer doesn't use that correctly, they could still end up exposing error messages that contain sensitive data.
> Zeev > -- Chase Peeler chasepee...@gmail.com
