Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106455 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 31538 invoked from network); 8 Aug 2019 23:45:50 -0000 Received: from unknown (HELO mail-ua1-f48.google.com) (209.85.222.48) by pb1.pair.com with SMTP; 8 Aug 2019 23:45:50 -0000 Received: by mail-ua1-f48.google.com with SMTP id c4so10148553uad.1 for ; Thu, 08 Aug 2019 14:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kke8oLSzWy3B+YZ/TkdIVFsgwncrtB4lpXAcew94+oM=; b=rPxABvkqANtmBtyhHDgZZ3tcGZ4JpygFeE7wdkeMZ3hylr1OCQXOdI3YbbszWAja6o jz77mRzJ81IyLJVZl21PdBKhIFSGPjHk0lRMfnnVVq1m4zRhLuuD5wgSUQcK1FqDfRVr v361LNyr7eN0xoY95giEhbdNivKQgle/rESK2TCstt+FZDUQEccVAd2rTx7raP5vaJQY Qy3jt53BMWI2q/Nf8exiSPtmZN2f88cVPNf1vQOtw2SYnTy1bOCDaXDfsYagtH/KS4KT X1z7d5kfoczG2ImmjK7RlKrtqy6U79Hb9GiV+JZ+L5O81+hwH6GWzvcspz2J6KBJfeWA RmGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kke8oLSzWy3B+YZ/TkdIVFsgwncrtB4lpXAcew94+oM=; b=Zkx7kY3xLLzB5e7D4cA4fQkpCtmYmyk55jzwQ5zAt56KTAUw1AlwMa0lHvFNTUa6Qa acOfC4BUPBUP5B5l0ze4y3jWf9D0odc3oWDpmy7zW8K6J74CPYLUj8IVINosD9nw7ibY ER6UdkHG9dUyB8WIbZwg2Z+uff9scMOI3SoIGhY8EL7sM2FG0sRH1/tZZgugydIPmltd 0Ei2zqy7fG6gkvxYgS+iDOGYyh1gbYUYJ9snih7nUOfQUU1icm+zLNTDwEPGDmidHJhr 5OM9sXBFj/RwNqUCdu/waexO/8dtunSMdt3QSkV5S5VIoUw0KsrGx1D1rhpgY2/ebT9h Tslg== X-Gm-Message-State: APjAAAX9Xfpevse5NIDKAg5vPc29vO2Jq+5qe971dNVBpD7ZwUqrn3TC oaHjnI3PjaWYXxqOPjAaD/jd4vQkGxIyAVgy9Y/LZs9b X-Google-Smtp-Source: APXvYqxal5cMEx+PPpx1ZU8KksCJYtavHMCz1xK834iFj94Us7cIS3EeP3Zx2ccn8yt0Kq7jNP8+3Pdln0I28DxU1Pc= X-Received: by 2002:ab0:6896:: with SMTP id t22mr6497366uar.127.1565298783828; Thu, 08 Aug 2019 14:13:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 8 Aug 2019 17:12:52 -0400 Message-ID: To: Zeev Suraski Cc: bishop@php.net, PHP internals Content-Type: multipart/alternative; boundary="000000000000fa3e92058fa18537" Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again From: chasepeeler@gmail.com (Chase Peeler) --000000000000fa3e92058fa18537 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 8, 2019 at 3:35 PM Zeev Suraski wrote: > On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini wrote: > > > On Tue, Aug 6, 2019 at 7:34 AM G. P. B. > 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 > > > > 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 > > 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 " > > > 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 chasepeeler@gmail.com --000000000000fa3e92058fa18537--