Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83842
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54EE50CF.9090508@gmail.com>
References: <CAGa2bXbt9FAdRtW1GxDyT+G-4bWBACTso_DOizcSHmmgmSVtmA@mail.gmail.com>
	<CAGa2bXb5QEKOggRbUnmVHuib=P_tJ9_W+QyMa_SCpc7RmSCgSA@mail.gmail.com>
	<54EE50CF.9090508@gmail.com>
Date: Wed, 25 Feb 2015 23:04:02 +0000
Message-ID: <CALwr1GmoAxfbKvJYVLeL3wPXEKKbu1jKGkTFcG0KQ_Ogx172sA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Introduce script only include/require
From: padraic.brady@gmail.com (=?UTF-8?Q?P=C3=A1draic_Brady?=)

Hi Stanislav,

On 25 February 2015 at 22:46, Stanislav Malyshev <smalyshev@gmail.com> wrot=
e:
> Hi!
>
>> I saw you voted "no".
>> Could you share us the reason behind?
>
> I think I did, in my past messages to the list, but maybe I was not
> clear. I will repeat in short:
>
> 1. I think this RFC does not provide any security improvement, due to
> extreme ease with which the measures in this RFC can be circumvented by
> the attacker.

All of which you demonstrated by ignoring the example provided showing
what it mitigates, and creating your own example where no file
validation was executed. A case that the RFC was in no way designed to
prevent. You basically created a non-existing benefit, proved that the
non-existing benefit did not exist, and that is apparently your
reason.

Surprise. TRUE =3D=3D=3D TRUE.

I asked you back in a previous response to locate an example for which
the RFC was designed to prevent that would fail. That would have had
significant value to the discussion. I take it you found none.

> 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.

RFC does not claim any such protection. RFC does not, therefore, offer
such protection. RFC will not be documented as offering any such
protection.

But fine, users will magically make false assumptions that need to
stop validating files and fielding variables before they hit include.

> 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

A BC break targeting a major PHP version. Which can be configured
flexibly for those who need it, like Drupal.

As documented in the RFC.

> the above it does not provide even minor one.
>
> This is why I vote no and call everybody to do the same.

You keep ignoring that minor flaw in your claim where it does actually
provide a benefit in blocking PHP bearing JPEGs as one example
mentioned several times.

Is there some sort of meter on Internals where, in the red, there is
an obligation to fill it back up with FUD, logical fallacies and the
occasional fib?

Paddy

--
P=C3=A1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com