Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59483
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAORXhGJ+ptX=ER6=u1G0OKYqF=PJ=FX-qd9KR8=M2VKK5oBtGg@mail.gmail.com>
References: <CAORXhGJwmbjw3Zze3+-oFA2Mb_Z-2owVESraNMMs57RzjRRMbA@mail.gmail.com>
 <CAGa2bXbjiNMv0g6BBZkuTtUe66gz-p8mQxRk+_0fisiJUADRgQ@mail.gmail.com>
 <CAGa2bXYhS9QCWarTKyBgv3Vnh8D8S=+Vic-XQZm0w6dqrkpf6A@mail.gmail.com>
 <CAORXhG+y0P+dM9x1_uewp0sXpHoz_4WDbjAUoRf4Auxv6FcUUQ@mail.gmail.com>
 <CAGa2bXZUUqVaKmv7wyjUtXzD9VN=HjEwpFVOEmAHpo9QPePwWQ@mail.gmail.com> <CAORXhGJ+ptX=ER6=u1G0OKYqF=PJ=FX-qd9KR8=M2VKK5oBtGg@mail.gmail.com>
Date: Mon, 9 Apr 2012 14:48:24 +0900
Message-ID: <CAGa2bXZDebPaa0AeDdoNfidmt3+_i_KtUVwg=VH9FReopnOBmQ@mail.gmail.com>
To: Tom Boutell <tom@punkave.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: source files without opening tag
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi,

I modified the title.

> * include vs. require behavior (warning vs. error on failure)
> * once vs. every time (require_once vs. require)
>
> And we are proposing a third:

Then, better name would be require_script()/include_script().

However, this option will not solve script inclusion security
issues. Fixing security issues will not have much opposition,
but adding new syntax will.

I like embedded languages, but programmers can write vulnerable
code with it. Embed feature is better to be controlled by programmers/
administrators for better security.

Regards,

P.S. I'm uncomfortable with current PHP, since someone
may write "include $_GET['module']" or like for my systems.
This code raises fatal security issue with current PHP, but
it's not with my proposal.

--
Yasuo Ohgaki
yohgaki@ohgaki.net



2012/4/9 Tom Boutell <tom@punkave.com>:
> Thanks. However, would you please fix the summary on the RFC's page to
> match the summary in the actual RFC? As you have written it, it
> implies that support for <?php would be completely removed. This is
> not the case.
>
> As for adding a boolean parameter to the require keyword, as the RFC
> mentions there are already at least two distinctions already when
> requiring files in PHP:
>
> * include vs. require behavior (warning vs. error on failure)
> * once vs. every time (require_once vs. require)
>
> And we are proposing a third:
>
> * start in php mode vs. start in html mode
>
> We already have four keywords for requiring files. At this point it
> does not make sense to keep introducing more keywords (we would need 8
> with this change). Your boolean flag proposal keeps it to four
> keywords, but as soon as someone adds another flag it will become
> awkward to remember them. Since PHP does not have named parameters I
> think an associative array is the best way to go (especially with the
> new short syntax).
>
> Also I don't think it makes sense to forbid shifting into html mode
> later in the file, it could reduce support for the proposal needlessly
> - since it already lets people who want to write clean all-PHP files
> do so, and some of those people might have legitimate reasons to use
> HTML mode in the scope of a function or method (where it does not
> suddenly introduce whitespace without being explicitly called, etc).
>
> But if it really came down to it I could live with an "absolutely
> nothing but PHP" behavior when the code flag is true (supporting <?php
> when the flag is not set is a must of course).
>
> On Sun, Apr 8, 2012 at 6:45 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>> Hi,
>>
>> I talked on twitter.
>> Yes, he is kidding, but he is serious, too.
>>
>> I've added the RFC to Under Discussion and added
>> security issue description. I also added my proposal that
>> controls embed mode.
>>
>> BTW, I don't think we need new "require_path" why don't
>> we use
>>
>> require "file.php", ture;
>>
>> or some thing similar?
>> I prefer to use switch, since security countermeasure is
>> better to be enforced by switch.
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohgaki@ohgaki.net
>>
>>
>>
>> 2012/4/9 Tom Boutell <tom@punkave.com>:
>>> Moriyoshi was kidding, as near as I can tell (:
>>>
>>> To take it at face value though, the *cough* April 1st *cough*
>>> proposal of Moriyoshi calls for the complete abolition of the feature
>>> with no backwards compatibility with existing code that uses PHP as a
>>> template language... including most popular frameworks that sensibly
>>> obey a separation between class files and template files but still use
>>> PHP rather than a dedicated templating language for templates.
>>>
>>> I don't think that's realistic (and neither did the author it
>>> appears). Since PHP's usability as a template language may conceivably
>>> be improved by other proposals, it is undesirable as well even if you
>>> don't currently find PHP to be a suitable template language.
>>>
>>> Please read my proposal over carefully as it does address the obvious
>>> issues that make Moriyoshi's proposal possibly less than serious in
>>> intent (:
>>>
>>> I would oppose a php.ini flag for this as that gives us two
>>> incompatible versions of the current version of the language to worry
>>> about and makes the feature effectively unusable in reusable code.
>>> This approach has created problems before.
>>>
>>> On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote=
:
>>>> Hi,
>>>>
>>>> There is RFC that is written by Moriyoshi.
>>>> It's not listed in RFC page, though.
>>>>
>>>> https://wiki.php.net/rfc/nophptags
>>>>
>>>> I think these should be merged.
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Yasuo Ohgaki
>>>> yohgaki@ohgaki.net
>>>>
>>>>
>>>>
>>>> 2012/4/9 Yasuo Ohgaki <yohgaki@ohgaki.net>:
>>>>> Hi,
>>>>>
>>>>> Moriyoshi has created same entry on 4/1, but
>>>>> it seems it was deleted =A0already.
>>>>>
>>>>> Anyway, he had a patch for it.
>>>>>
>>>>> https://gist.github.com/2266652
>>>>>
>>>>> As I mentioned in other thread, we should better to have
>>>>> a switch to disable embed mode for security reasons.
>>>>>
>>>>> Regards,
>>>>>
>>>>> --
>>>>> Yasuo Ohgaki
>>>>> yohgaki@ohgaki.net
>>>>>
>>>>>
>>>>>
>>>>> 2012/4/9 Tom Boutell <tom@punkave.com>:
>>>>>> I have written an RFC proposing backwards-compatible support for
>>>>>> source files without an opening <?php tag:
>>>>>>
>>>>>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>>>>>
>>>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sur=
e
>>>>>> what the requirements are to get it added to the "Under Discussion"
>>>>>> session and get the ball rolling formally. Please enlighten and I'll
>>>>>> do whatever is required.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> --
>>>>>> Tom Boutell
>>>>>> P'unk Avenue
>>>>>> 215 755 1330
>>>>>> punkave.com
>>>>>> window.punkave.com
>>>>>>
>>>>>> --
>>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>>
>>>
>>>
>>>
>>> --
>>> Tom Boutell
>>> P'unk Avenue
>>> 215 755 1330
>>> punkave.com
>>> window.punkave.com
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>
>
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>