Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59549
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXY0fXX_SSYtsdw2xVqE=V6t+8B_-daPo5YrRd6E_HuPfQ@mail.gmail.com>
References: <CAORXhGJwmbjw3Zze3+-oFA2Mb_Z-2owVESraNMMs57RzjRRMbA@mail.gmail.com>
	<-5877502932356715576@unknownmsgid>
	<CAORXhGLPdAie6UFq+daJhUmDUqp7RaFFLa596XdzdtuCddf0Jw@mail.gmail.com>
	<-3647345967307864634@unknownmsgid>
	<CAORXhGKjg_L11dFGNHNfNygDH018=ZhytAy1vH+Ei8QHfry=cA@mail.gmail.com>
	<CAORXhG+K3XML-47+FDYdL5D717wDX7c59Pz8KgqjcP16+Ad12w@mail.gmail.com>
	<4F831FAE.2030208@ralphschindler.com>
	<4775322189440202047@unknownmsgid>
	<CAORXhGJSG6CJD5EAt_uZ7RjfjM345nfrVQz8t2ep4e3WhCeKMQ@mail.gmail.com>
	<4F833682.2000301@ralphschindler.com>
	<CAGa2bXYjJsfo6os_P1OvQ7jfmxeYUkZ+QK5r94nwNUsba-iWLA@mail.gmail.com>
	<4F833AB0.2060306@sugarcrm.com>
	<CAGa2bXa4U3ar2REYahyt_0pJH=mjNjvHUhmHpxL+Qkdy3tUZFQ@mail.gmail.com>
	<4F8340E6.90005@sugarcrm.com>
	<CAGa2bXY0fXX_SSYtsdw2xVqE=V6t+8B_-daPo5YrRd6E_HuPfQ@mail.gmail.com>
Date: Mon, 9 Apr 2012 13:41:21 -0700
Message-ID: <CAKOpQSz2oTBCdgxsCBoeDUJaG=hA9Hx-S6jMJ7rtqcn1hbEnAw@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016e6d625746aed1f04bd450717
Subject: Re: [PHP-DEV] RFC: source files without opening tag
From: kris.craig@gmail.com (Kris Craig)

--0016e6d625746aed1f04bd450717
Content-Type: text/plain; charset=ISO-8859-1

Tom,

On Mon, Apr 9, 2012 at 1:20 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi,
>
>
> 2012/4/10 Stas Malyshev <smalyshev@sugarcrm.com>:
> > Hi!
> >
> >>> I'm not sure I follow - which PHP vulnerability you are talking about?
> >>
> >> Local file includes. (LFI)
> >
> > I'm not sure I understand - where's the vulnerability?
> >
> >> There is a null byte protection for LFI and I really like to the
> protection.
> >> It's also beneficial to other problems. However, it would not help codes
> >> like "include $_REQUEST['var']"
> >
> > Don't write such code. It's like saying exec() function is a
> > "vulnerability" in libc. You instruct PHP to run code based on user
> > input - that's what PHP will be doing, it's not a "vulnerability" by any
> > definition.
>
> I agree. Programmer should not write that.
>
> I would not propose the RFC if PHP is used as embedded languages mainly
> or the vulnerability is non fatal. By making embedded mode non mandatory,
> almost all issues will be gone. Why shouldn't we?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Honestly, I would suggest just getting rid of "Option 1" altogether.  It
would end up over-complicating this to such a degree that any usefulness it
might serve would be considerably diminished.

As for embedded HTML, if you allow the ?> tag in these .phpp files, then
that pretty much negates the entire purpose of having them to begin with.
Essentially, you'd just be changing it so that, instead of defaulting to
"?>" when no tag is present, it defaults to "<?php".  I just don't see any
value in that as a developer.

A developer should *not* be including in a .phpp file classes that contain
HTML within the ?> tag, period.  If they need to include something that has
that, they should do it in a regular .php file.  An "HTML-less" PHP file
needs to be exactly that; no direct HTML allowed.  Otherwise, the RFC is
completely and utterly pointless IMHO.


I think this would be awesome for PHP 6, but I'll have to vote against it
if you settle on using "Option 1" and/or allow ?> content to be
embedded/included in .phpp files.  If we differentiate based solely on the
file extension and keep ?> tags out of it, then I'll definitely support it!

--Kris

--0016e6d625746aed1f04bd450717--