Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:29535 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1497 invoked by uid 1010); 19 May 2007 07:12:31 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 1482 invoked from network); 19 May 2007 07:12:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 May 2007 07:12:31 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 207.126.228.149 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 207.126.228.149 rsmtp1.corp.yahoo.com FreeBSD 4.7-5.2 (or MacOS X 10.2-10.3) (2) Received: from [207.126.228.149] ([207.126.228.149:37108] helo=rsmtp1.corp.yahoo.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F4/42-00717-D53AE464 for ; Sat, 19 May 2007 03:12:31 -0400 Received: from trainburn-lm-corp-yahoo-com.local (socks2.corp.yahoo.com [216.145.54.7]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l4J7CCBA083891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 May 2007 00:12:15 -0700 (PDT) Message-ID: <464EA33E.2010505@lerdorf.com> Date: Sat, 19 May 2007 15:11:58 +0800 User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Stanislav Malyshev CC: Greg Beaver , php-dev References: <464DCB8C.90803@chiaraquartet.net> <464DE94E.5030002@zend.com> In-Reply-To: <464DE94E.5030002@zend.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] potential solution to user streams + allow_url_include=off From: rasmus@lerdorf.com (Rasmus Lerdorf) Stanislav Malyshev wrote: >> allow_url_(include|fopen) applies to them. As such, because >> allow_url_(include|fopen) are disabled by default in PHP 6, this will > > Disabling allow_url_fopen by default is the second mistake. What's wrong > with it? Wasn't the sole reason for having allow_url_include to allow > url_fopen work while protecting includes? Oh yes, somebody could say > fopen+eval. So, somebody could also say curl_open+eval, so what? I'm on a really crappy connection in China right now, so I haven't read the whole thread, but this caught my eye. Since when is allow_url_fopen disabled by default? It certainly isn't in my PHP6 checkout from a couple of days ago. And it shouldn't be disabled by default. -Rasmus