Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59717 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84566 invoked from network); 11 Apr 2012 06:08:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Apr 2012 06:08:40 -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.193 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.193 smtp193.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.193] ([67.192.241.193:36889] helo=smtp193.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7D/A3-18401-7EF158F4 for ; Wed, 11 Apr 2012 02:08:39 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp9.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id D14563C01EE; Wed, 11 Apr 2012 02:08:36 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp9.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 6543C3C012F; Wed, 11 Apr 2012 02:08:36 -0400 (EDT) Message-ID: <4F851FE4.7000706@sugarcrm.com> Date: Tue, 10 Apr 2012 23:08:36 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Yasuo Ohgaki CC: John Crenshaw , "internals@lists.php.net" References: <4F850D06.10701@sugarcrm.com> <4F8515AF.8060706@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > If attacker can inject code at the beginning or make valid syntax > at the beginning, they can succeed injection. This is true not > only for PHP, but also Ruby/Perl/Python. This is exactly my point. Since it does not solve the problem that you are presenting (I am still not convinced it's our problem, but for the same of discussion let's assume for now it is so) - why exactly would we want to do it? I'm afraid we'd have another safe_mode scenario on our hands here, where we lure users into complacency with false sense of security, while not actually providing it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227