Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:57198 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 39147 invoked from network); 4 Jan 2012 20:03:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jan 2012 20:03:05 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.161.170 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.161.170 mail-gx0-f170.google.com Received: from [209.85.161.170] ([209.85.161.170:65524] helo=mail-gx0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D0/6F-50667-770B40F4 for ; Wed, 04 Jan 2012 15:03:05 -0500 Received: by ggnv1 with SMTP id v1so11182858ggn.29 for ; Wed, 04 Jan 2012 12:03:01 -0800 (PST) Received: by 10.50.88.129 with SMTP id bg1mr69313825igb.10.1325707380811; Wed, 04 Jan 2012 12:03:00 -0800 (PST) Received: from [192.168.200.5] (c-50-131-44-225.hsd1.ca.comcast.net. [50.131.44.225]) by mx.google.com with ESMTPS id l35sm192771684ibj.0.2012.01.04.12.02.58 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 12:02:59 -0800 (PST) Sender: Rasmus Lerdorf Message-ID: <4F04B071.8080102@php.net> Date: Wed, 04 Jan 2012 12:02:57 -0800 Organization: PHP Development Team User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Nikita Popov CC: Ferenc Kovacs , Stas Malyshev , Laruence , PHP Internals References: <4F048A03.4070408@sugarcrm.com> <4F04A172.7080509@sugarcrm.com> <4F04AA8E.6020701@sugarcrm.com> <4F04AD6D.80608@php.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: another fix for max_input_vars. From: rasmus@php.net (Rasmus Lerdorf) On 01/04/2012 11:54 AM, Nikita Popov wrote: > On Wed, Jan 4, 2012 at 8:50 PM, Rasmus Lerdorf wrote: >> Since it is one of these remotely-triggered errors that you can't >> program around, it should probably be suppressed when display_errors is >> on. There is another precedence for this, but I am drawing a blank on >> where else we did this right now. >> >> -Rasmus > You mean like with htmlspecialchars() before PHP 5.4? Please don't. > It's really non-obvious to start hiding errors as soon as you enable > error display. But there is a very valid security concern here. People can usually run safely with display_errors enabled if their code is well-written. They can check for potential errors and avoid them. This one can't be checked for and you could easily write a scanner that scoured the Net for sites with display_errors enabled by sending a relatively short POST request to each one and checking for this error. And there is absolutely nothing people could do about this short of turning off display_errors which we know from experience a lot of people just don't do no matter how much we suggest it. The alternative is to just not have any error message at all. That avoids the discrepancy between the error messages with display_errors on and off. -Rasmus