Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83850
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net
Date: Thu, 26 Feb 2015 00:30:03 +0100
Message-ID: <2kmsealj38h1k995ninhqfr9q4fr4cascq@4ax.com>
References: <CAGa2bXbt9FAdRtW1GxDyT+G-4bWBACTso_DOizcSHmmgmSVtmA@mail.gmail.com> <CAGa2bXb5QEKOggRbUnmVHuib=P_tJ9_W+QyMa_SCpc7RmSCgSA@mail.gmail.com> <54EE50CF.9090508@gmail.com> <54EE5634.1040300@seld.be>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Introduce script only include/require
From: phpdev@ehrhardt.nl (Jan Ehrhardt)

Jordi Boggiano in php.internals (Wed, 25 Feb 2015 23:09:40 +0000):
>On 25/02/2015 22:46, Stanislav Malyshev wrote:
>> 2. I think this RFC provides false sense of security for people that
>> create vulnerable code and lets them think it's OK to have variable
>> includes without adequate safety, since they are "protected" by these
>> changes.
>
>People that are clueless already do not validate anything and are *NOT* 
>protected by this RFC. People that know what they are doing probably do 
>not need this patch. So the way I see it it's a win for random crappy 
>code out there, and a noop at worst for the others.
>
>> 3. I think it causes significant BC break which might be warranted in
>> case it provides major improvement in security, but IMO in the light of
>> the above it does not provide even minor one.
>
>A way to mitigate this might be to change the default to include a few 
>more common extensions like phtml, inc, or whatever. As those are all 
>commonly associated with PHP and offer no good reason to be allowed in 
>user uploads, I guess it's safe.

Better yet: allow all by default. Then there is no BC break and nothing
changes for clueless people. People with clue can make their own choice
to use or not to use.

Jan