Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72430 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16953 invoked from network); 10 Feb 2014 07:56:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Feb 2014 07:56:40 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.115 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.115 smtp115.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.115] ([108.166.43.115:44113] helo=smtp115.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 63/C0-12747-73688F25 for ; Mon, 10 Feb 2014 02:56:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C67101B809D; Mon, 10 Feb 2014 02:56:36 -0500 (EST) X-Virus-Scanned: OK Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 704D21B80CB; Mon, 10 Feb 2014 02:56:36 -0500 (EST) Message-ID: <52F88633.6000308@sugarcrm.com> Date: Sun, 09 Feb 2014 23:56:35 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Yasuo Ohgaki , "internals@lists.php.net" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] No PHP tags From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > "Optional PHP tags by php.ini and CLI options" RFC has been discussed very > long time. > > https://wiki.php.net/rfc/nophptags > > I would like to know is there anyone who would like not to have > this. Yes. Such change would create a lot of complications on dealing with PHP files, as syntax and parsing would be dependent on ini values, which means one can not predict without knowing the exact environment how specific file is going to be parsed. We already made that mistake with short tags, and I don't think it makes sense to make it again. We do not need to fragment PHP into two incompatible codebases, so that some libraries only run with one set of settings and others run with different set of settings. > I think it's good counter measure for LFI, but you might have > different perspective. This is not a serious countermeasure and can not be relied on as a security measure. The correct security is not including local files with unsanitized names and use open_basedir if required. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227