Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:57743 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 51591 invoked from network); 5 Feb 2012 20:28:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Feb 2012 20:28:13 -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.153 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.153 smtp153.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.153] ([67.192.241.153:50369] helo=smtp153.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E6/50-48677-C56EE2F4 for ; Sun, 05 Feb 2012 15:28:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp15.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 728BE3001C0; Sun, 5 Feb 2012 15:28:09 -0500 (EST) X-Virus-Scanned: OK Received: by smtp15.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id EF0A03001B9; Sun, 5 Feb 2012 15:28:08 -0500 (EST) Message-ID: <4F2EE658.2010504@sugarcrm.com> Date: Sun, 05 Feb 2012 12:28:08 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: John Crenshaw CC: Derick Rethans , Nikita Popov , PHP internals References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Removing this would obviously be an inconvenience for some people, > but getting your server hacked is also an inconvenience, and hackers > don't give you nice warnings with file and line number. I like the > idea of doing _something_ here. Deprecate now and remove later sounds > fair. Inconvenience is fairly minimal - you can easily rewrite it with preg_replace_callback, which given we have now anon functions is no more verbose, much easier to understand and has no security problems whatsoever, seems to be a win. The problem with /e is not people that do not sanitize, the problem is that sanitizing properly is not easy and people regularly mess it up and don't even know it. Yes, that means that some code will have to be patched - but it can be easily done, even in backwards-compatible way since preg_replace_callback is available since forever. And the resulting code will also be faster (though probably it wouldn't matter :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227