Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72164 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3226 invoked from network); 4 Feb 2014 00:36:37 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Feb 2014 00:36:37 -0000 Authentication-Results: pb1.pair.com header.from=swhitemanlistens-software@cypressintegrated.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=swhitemanlistens-software@cypressintegrated.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender) X-PHP-List-Original-Sender: swhitemanlistens-software@cypressintegrated.com X-Host-Fingerprint: 173.1.104.101 rproxy2-b-iv.figureone.com Received: from [173.1.104.101] ([173.1.104.101:54747] helo=rproxy2-b-iv.figureone.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5D/E1-35654-41630F25 for ; Mon, 03 Feb 2014 19:36:36 -0500 Received: from bad.dop.co ([108.12.130.219]) by rproxy2-b-iv.figureone.com (Brand New Heavy v1.0) with ASMTP id QCO03930 for ; Mon, 03 Feb 2014 16:36:30 -0800 Date: Mon, 3 Feb 2014 19:36:12 -0500 Reply-To: Sanford Whiteman X-Priority: 3 (Normal) Message-ID: <258999488.20140203193612@cypressintegrated.com> To: =?iso-8859-15?Q?P=E1draic_Brady?= In-Reply-To: <755946425.20140203190503@cypressintegrated.com> References: <344075933.20140203143339@figureone.com> <10337340.20140203171726@cypressintegrated.com> <755946425.20140203190503@cypressintegrated.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Windows Peer Verification From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman) Anyway, I think we get off-topic with discussions of those who *knowingly* write insecure code, e.g. manually turning off secure options to save effort. Also think it is unnecessary _in the context of a related language change_ to discuss whether users writing insecure code due to ignorance of PHP's defaults is no excuse, a partial excuse, or a full excuse. All that matters is that the default options were being trusted in the real world by real -- by job description, if not competence -- developers. If it needs to be fixed, we should fix it, but with no extra grudges in the implementation. When we bear a grudge against our own users for "forcing" a language change we leave the doors open for punishing them with the implementation of that change. This is my main argument with Daniel: either we accept that we are breaking people's setups with a change *regardless* of their ultimate responsibility for that change, or we don't make the change. Stating that it's dirt-simple to make such a change is a way of punishing a subset of users who aren't any worse developers than the rest, and perhaps most unfortunately it targets a minority of users who already get the short end of the stick when it comes to extensions, etc., and now will be told that their code is less secure than their *nix counterparts' code -- even though the *nix side is going to get more secure without doing a whit of work. I guess the laissez-faire attitude about Windows users is what sticks in my craw, like they get a bizarre hybrid of respect and disrespect with this patch. -- S.