Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:57204 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48320 invoked from network); 4 Jan 2012 20:29:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jan 2012 20:29:22 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.123 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.123 smtp123.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.123] ([67.192.241.123:41067] helo=smtp123.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 73/51-50667-0A6B40F4 for ; Wed, 04 Jan 2012 15:29:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp12.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id BCF0E3C03C3; Wed, 4 Jan 2012 15:29:17 -0500 (EST) X-Virus-Scanned: OK Received: by smtp12.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 24A163C00D3; Wed, 4 Jan 2012 15:29:17 -0500 (EST) Message-ID: <4F04B69C.10102@sugarcrm.com> Date: Wed, 04 Jan 2012 12:29:16 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Rasmus Lerdorf CC: Nikita Popov , Ferenc Kovacs , Laruence , PHP Internals References: <4F048A03.4070408@sugarcrm.com> <4F04A172.7080509@sugarcrm.com> <4F04AA8E.6020701@sugarcrm.com> <4F04AD6D.80608@php.net> <4F04B071.8080102@php.net> In-Reply-To: <4F04B071.8080102@php.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: another fix for max_input_vars. From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > 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 Oh no. Nobody should or can safely run production with display_errors. Everybody thinks their code is well-written, but display_errors should never be enabled in production, however high is your opinion of the code. I'm afraid people now will start quoting this saying "ok, yeah, if you're a bad programmer, disable display_errors, but I'm a good programmer, my code is solid, I even have a dozen of unit tests, so I just go ahead and enable display_errors" and then we have this sad state of affairs where sites spill out error messages that are never supposed to be seen by clients because developers thought it can never happen. > 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. I don't think it's a good idea to add such magic, as correctly noted, it will make people that are working properly - display off in production, on in development - work harder and have trouble, all in the name of cuddling people that run misconfigured servers and ignore the advice that is being repeated for years by now. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227