Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] RFC: source files without opening tag

Posted by Tom Boutell 
Ángel González
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 09:30PM
On 09/04/12 19:36, Luke Scott wrote:
> On Apr 9, 2012, at 10:23 AM, Tom Boutell <[email protected]> wrote:
>> Also, your objection - that 'require_code' is confusing - would most
>> likely be an issue for a handful of people who write autoloaders.
>> Those clean PHP class files are almost always autoloaded.
> Not really. Has nothing to do with auto loaders.
>
> require_code - A literal string? Is this eval?
>
> require_path - A directory?
>
> require_file - What kind of file?
A php file, of course :)


> You have to look at the keywords you're proposing and try to explain
> then without prior knowledge or documentation.
But if you come accross them you'd see something like:
require_code "setup.php";

Which is much more clear.

> These keywords are also ambiguous. require/include are well understood
> for including code not templates. Not just for PHP.
PHP has allowed to require HTML forever. Given it's php developers the main
target, it is not a huge argument that they may get confused by
require_file
doing what require has always done.

I admit require_code for a full HTML file* may be slightly odd, but
require_file
is completely aseptic about that.


* Which should instead have been loaded with readfile()...


> require_template on the other hand is clear and to the point. It's
> hard to make the same kind of assumptions as you can with the other
> keywords. And with those who know PHP it's readily apparent
> require_template could mean short tags whereas the other leave you
> scratching your head.
Except that you're breaking compatibility by designing it the opposite way.
It may have been the perfect idea if we were designing PHP from scratch, but
we're not. This is a 17 years old language.




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yasuo Ohgaki
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 09:40PM
Hi,

Tom's FRC is trying to introduce tag less PHP script.
However, it does not fix well known PHP vulnerability. i.e. LFI/RFI
IMHO, this change introduce more complexity and do not solve
any problem.

Making PHP tag a non mandatory would solve the well known
vulnerability and do not introduce any new function. It's also fully
compatible to existing codes.

https://wiki.php.net/rfc/nophptags

There would be many developers/administrators who would
like to be protected from code like "include $_GET['var']".
nophptags RFC protects systems from this kind of fatal
vulnerable codes.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stas Malyshev
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 09:40PM
Hi!

> Tom's FRC is trying to introduce tag less PHP script.
> However, it does not fix well known PHP vulnerability. i.e. LFI/RFI
> IMHO, this change introduce more complexity and do not solve
> any problem.

I'm not sure I follow - which PHP vulnerability you are talking about?

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yasuo Ohgaki
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 09:50PM
Hi,

2012/4/10 Stas Malyshev <[email protected]>:
> Hi!
>
>> Tom's FRC is trying to introduce tag less PHP script.
>> However, it does not fix well known PHP vulnerability. i.e. LFI/RFI
>> IMHO, this change introduce more complexity and do not solve
>> any problem.
>
> I'm not sure I follow - which PHP vulnerability you are talking about?

Local file includes. (LFI)
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']"

LFI is fatal vulnerability. It would be better kill the vulnerability
if we can. IMHO.

Regards,

P.S. Mandatory embedded script mode does not make much sense lately.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Luke Scott
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 10:00PM
On Apr 9, 2012, at 12:27 PM, "Ángel González" <[email protected]> wrote:

> On 09/04/12 19:36, Luke Scott wrote:
>> On Apr 9, 2012, at 10:23 AM, Tom Boutell <[email protected]> wrote:
>>> Also, your objection - that 'require_code' is confusing - would most
>>> likely be an issue for a handful of people who write autoloaders.
>>> Those clean PHP class files are almost always autoloaded.
>> Not really. Has nothing to do with auto loaders.
>>
>> require_code - A literal string? Is this eval?
>>
>> require_path - A directory?
>>
>> require_file - What kind of file?
> A php file, of course :)

I'm sorry but the word "file" is highly non descriptive. Remember to
consider newcomers to the language as well. Consider also the are
functions that already make use of this word such as: file,
file_get_contents, file_put_contents, readfile, etc...

>
>
>> You have to look at the keywords you're proposing and try to explain
>> then without prior knowledge or documentation.
> But if you come accross them you'd see something like:
> require_code "setup.php";
>
> Which is much more clear.

You also can't make the assumption that someone is going to learn this
from existing code.

>
>> These keywords are also ambiguous. require/include are well understood
>> for including code not templates. Not just for PHP.
> PHP has allowed to require HTML forever. Given it's php developers the main
> target, it is not a huge argument that they may get confused by
> require_file
> doing what require has always done.

And it's considered bad practice. A majority of PHP developers avoid
it. The only time they do this is for templates in very small
projects. For larger projects using PHP as a template engine is
unmaintainable.

If you look at code on Github I'm sure you'll find most code starting
with <?php and that's it. Perhaps a handful stick ?> at the end... But
even fewer are going to break out of PHP just to print something.
Especially with nowdoc.

We aren't trying to be compatible with PHP 4. Most of what I have said
has been the case since PHP 5.1. At least 5.2 (which is no longer
supported).

Luke

>
> I admit require_code for a full HTML file* may be slightly odd, but
> require_file
> is completely aseptic about that.
>
>
> * Which should instead have been loaded with readfile()...
>
>
>> require_template on the other hand is clear and to the point. It's
>> hard to make the same kind of assumptions as you can with the other
>> keywords. And with those who know PHP it's readily apparent
>> require_template could mean short tags whereas the other leave you
>> scratching your head.
> Except that you're breaking compatibility by designing it the opposite way.
> It may have been the perfect idea if we were designing PHP from scratch, but
> we're not. This is a 17 years old language.
>
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stas Malyshev
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 10:10PM
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.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Luke Scott
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 10:10PM
On Apr 9, 2012, at 12:16 PM, "Ángel González" <[email protected]> wrote:

> On 09/04/12 20:23, Chris Stockton wrote:
>> Hello,
>> Although I am not very interested in this feature, if it is
>> implemented I like the idea of flags instead of introducing new
>> keywords. Maintaining backwards compatibility would be great
>> considering the benefit to the feature to be completely honest (and in
>> disagreement to many people, but I do understand the reasoning for
>> everyone's interest in it) is extremely minor in my eyes.
>>
>> In addition I would suggest maybe using PHP_INCLUDE_* as a place for
>> these constants to live.
>>
>> -Chris
> That would still be a parse error.
> Either
> include "file.php", 5;
> or
> include ("file.php", 42);
>
> Fails with a parse error about unexpected ','
>
> On the other hand, a new keyword can be written in a backwards
> compatible way by making it look like a function call in a non-taken branch:

The keyword "abstract" would cause a parse error for older versions of
PHP. Backwards compatibility is having existing code work with the
current versions.

To make new code compatible with older versions of PHP you simply
don't use the keyword/constant.

>
> *if ( version_compare(PHP_VERSION*, '5.5', '<') )
> include_once $file;
> else
> require_code($file, array( 'once'=>true, 'warn' => 'ignore' ) );

I'm fairly certain that wouldn't work either. Require and friends are
constructs, not functions.

Luke

>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yasuo Ohgaki
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 10:20PM
Hi,

2012/4/10 Stas Malyshev <[email protected]>:
> Hi!
>
>> Tom's FRC is trying to introduce tag less PHP script.
>> However, it does not fix well known PHP vulnerability. i.e. LFI/RFI
>> IMHO, this change introduce more complexity and do not solve
>> any problem.
>
> I'm not sure I follow - which PHP vulnerability you are talking about?

Not many people read RFC, so I should have written example attack scenario.
Because PHP is embedded scripting language, PHP code may be embedded
anywhere/any files. One convenient place is session storage. i.e. file
save handler.

==Exploiting LFI without file uploads==

1. Find FLI vulnerable application.
2. Find a way to inject $_SESSION
3. Use session file to execute arbitrary PHP code.

Files save handler is the default, attacker knew his/her session ID and
can guess session.save_path easily. Therefore, there are high possibility
that attacker could take control of web server via LFI.

== Possible protections ==

It's possible to prevent session FLI by adding "<?php die()?>" to top
of session data. It's not clean solution and has compatibility issue with
other systems. (e.g. There are PERL/Ruby/Python scripts that decodes
PHP session data) It's also possible that makes save_path unpredictable.
It won't worth to do that. IMO.

If developers/administrators could make PHP tag non mandatory, almost
all LFI could be protected by simple file validation. i.e. Check the first line
if it begins with "<?php"


== Validation Issues ==

Invalidating PHP script contained file is not simple. Attacker can inject
PHP code into any file and anywhere.

1. "<?", "<%" may occur in binary
2. <script language= is common in HTML

Forcing programmers to check binary/HTML/mail messages/etc would be
impossible.

== Solution ==

Please take a look at the RFC.
https://wiki.php.net/rfc/nophptags

Regards,


--
Yasuo Ohgaki
yohgaki@ohgaki.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Luke Scott
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 10:20PM
Tom,

On Apr 9, 2012, at 11:26 AM, Tom Boutell <[email protected]> wrote:

> Ralph, you make good points. And Luke's opposition to my new keyword
> is probably going to be shared by others (like Chris who just chimed
> in).
>
> So the more I think about it, the more a set of constants that can be
> OR'd together is a better idea than my associative array proposal. And
> it's best to keep the original four keywords, adding the second,
> optional parameter as a way of passing a combination of flags that
> alter their behavior.
>
> Also that set of bits could include the 'once' and 'warning' flags, so
> if you really want to just use the 'require' keyword and determine
> dynamically which behavior you get, you can. So there are no new
> keywords needed.
>
> Also, the presence of any bit that is not recognized by this version
> of PHP should be an error. It's better to stop than to completely
> misparse a file (:
>
> I don't think long-ish constants are a real problem since this
> functionality would very likely be written just a few times in
> autoloaders (as is typical in almost any project that would be
> interested in .phpc files in the first place) rather than repeatedly
> all over the place in every file (as with old-fashioned uses of
> 'require', and various templating situations).
>
> I will revise the RFC shortly

I do like constants. I would recommend:

CODE
TEMPLATE
SILENT

....with some sort of prefix like INCLUDE_* or INC_*.

I would very much like to have the ability to prevent just the
warnings generated by include... Primarily for an auto loader.
Include/require supports include path, file_exists does not. You can
avoid a stat on include/require with APC, with file_exists you cannot.

Perhaps that belongs in a different RFC... But if we're thinking of
using constants it would be a nice thing to mention.

Luke

>
> On Mon, Apr 9, 2012 at 1:51 PM, Luke Scott <[email protected]> wrote:
>> On Apr 9, 2012, at 10:44 AM, Ralph Schindler <[email protected]> wrote:
>>
>>> Hey Tom,
>>>
>>> An idea, why not overload require/include with a second parameter that simply enforces an include mode. For example
>>>
>>> // in some autoloader (include, requires, and *_onces)
>>> include $pathToFile, INCLUDE_MODE_PHP_ONLY;
>>>
>>> This would tell the parser/executor to start in PHP mode and never leave it, that way, ending tags would throw a runtime/execution error.
>>>
>>> Other constants and behaviors could be:
>>>
>>> INCLUDE_MODE_PHP_START;
>>> INCLUDE_MODE_PASSTRHOUGH_START; (the current and default behavior)
>>>
>>> This would have the least amount of impact on BC, and seeminlyg would be a friendly change to the lexer/syntax.
>>>
>>> Thoughts?
>>
>>
>> If this were to happen:
>>
>> - I would prefer much shorter elegant constants.
>>
>> - A constant for suppressing warnings thrown by include without
>> suppressing warnings/errors by the actual file -- I think we can all
>> agree @include is counter productive since it does much more that
>> suppress warnings thrown by include (even parse errors!).
>>
>> Luke
>>
>>
>>>
>>> -ralph
>>>
>>>
>>>
>>> On 4/9/12 12:23 PM, Tom Boutell wrote:
>>>> Also, your objection - that 'require_code' is confusing - would most
>>>> likely be an issue for a handful of people who write autoloaders.
>>>> Those clean PHP class files are almost always autoloaded.
>>>>
>>>> On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell<[email protected]> wrote:
>>>>> I see what you're saying, but you're proposing a new keyword to
>>>>> include code that does what plain old 'require' does now (assuming
>>>>> it's not a nice clean class file that is being included). Which means
>>>>> that valid code today is busted code once this feature comes out. That
>>>>> seems like a very hard sell.
>>>>>
>>>>> On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott<[email protected]> wrote:
>>>>>> On Apr 9, 2012, at 9:16 AM, Tom Boutell<[email protected]> wrote:
>>>>>>
>>>>>>> It sounds like you are proposing to gradually kill the use of PHP for
>>>>>>> templating entirely, which I don't think is something people would
>>>>>>> vote for.
>>>>>>
>>>>>> I'm not saying that at all. I'm saying that PHP code should be clearly
>>>>>> separated from template code.<?php should be optional at the start of
>>>>>> the file and IF a keyword should be added it should be for templates
>>>>>> and short-tags.
>>>>>>
>>>>>> 99% of modern PHP code is going to be classes that start with<?php
>>>>>> and omit the ending ?> (since PHP 5 due to how easy it is for white
>>>>>> space to end up on the tail end of a file). this is even the case with
>>>>>> procedural code.
>>>>>>
>>>>>> Half the PHP frameworks out there have their own template engine
>>>>>> because they can do a lot more than what short tags offer. Example:
>>>>>> Twig offers template inheritance.
>>>>>>
>>>>>> Introducing a keyword for PHP code without the<?php tag is
>>>>>> impractical. It makes much more sense to have a keyword for templates.
>>>>>>
>>>>>> For non-template code the starting<?php tag should always work as it
>>>>>> has before for backwards compatibility. The difference is you cannot
>>>>>> use ?> and text before the opening<?php tag is either ignored or
>>>>>> throws an error.
>>>>>>
>>>>>>> I sometimes use perfectly good older frameworks that do use
>>>>>>> .php files for templating in a reasonable way, and I'm one of the
>>>>>>> advocates for migrating away from starting everything with<?php. I
>>>>>>> would have to vote against it myself.
>>>>>>
>>>>>> And those files can be included with something like require_template
>>>>>> or you can turn off the option in the ini file.
>>>>>>
>>>>>> The point is in EITHER MODE a php file that starts with<?php will
>>>>>> work as it did before. The new mode would just disallow you to break
>>>>>> out of PHP code with ?>.
>>>>>>
>>>>>>> There's no reason to kill good
>>>>>>> code that passes its tests just because it uses inline HTML. I won't
>>>>>>> even know I have that code in my project from some third party library
>>>>>>> until I find out the hard way. No, just no. (:
>>>>>>
>>>>>> I'm not trying to kill anything. In fact what I'm proposing would be a
>>>>>> smooth transition to something that is already done. The difference is
>>>>>> at some point you won't be able to do this:
>>>>>>
>>>>>> <?php
>>>>>> class Object
>>>>>> {
>>>>>> public function output()
>>>>>> {
>>>>>> ?>
>>>>>> Print me!
>>>>>> <?php
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> I cringe every time I see this. There is no excuse since we have here/nowdocs.
>>>>>>
>>>>>> For people that use PHP as a template there can be other options. I'm
>>>>>> not totally against a new keyword, but I am against a new keyword for
>>>>>> including normal PHP code. It just doesn't make sense. No matter what
>>>>>> you name it (require_code, require_file, require_path) it's damned
>>>>>> confusing. If you did it the other way around its much clearer:
>>>>>> require_template.
>>>>>>
>>>>>> With require_template you're also free to expand template
>>>>>> functionality while keeping code clearly separated.
>>>>>>
>>>>>>> I did propose one new keyword, but by proposing one keyword with a
>>>>>>> future-friendly syntax instead of four new keywords I'm attempting to
>>>>>>> help with the pollution problem.
>>>>>>
>>>>>> It's not as much as adding a keyword as it is what keyword you're adding.
>>>>>>
>>>>>> I hope the way I've explained things makes sense.
>>>>>>
>>>>>> Luke
>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott<[email protected]> wrote:
>>>>>>>> Tom,
>>>>>>>>
>>>>>>>> As I've said before I don't think new keywords are the answer. They
>>>>>>>> will just pollute the language even further.
>>>>>>>>
>>>>>>>> I also don't think an ini setting is a bad thing either. It is often
>>>>>>>> used in PHP as a way to transition from way of doing things to
>>>>>>>> another. First you introduce it with it being off by default, then on
>>>>>>>> by default, then deprecate the old behavior. It's quite normal in
>>>>>>>> PHP's history.
>>>>>>>>
>>>>>>>> In another email someone mentioned doing two rfcs. In both cases are
>>>>>>>> we talking about removing<?php ? Because it's become somewhat
>>>>>>>> confusing to keep track of what is being talked about. If that is the
>>>>>>>> case, continue reading.
>>>>>>>>
>>>>>>>> I would prefer the starting<?php tag be optional rather than removed.
>>>>>>>> Just explicitly forbid the ending ?> tag and treat text before the
>>>>>>>> opening<?php tag differently. Perhaps ignore it (rather than print)
>>>>>>>> or throw an error.
>>>>>>>>
>>>>>>>> That is at least how I would prefer the "code" mode as most
>>>>>>>> non-template files only start with<?php. It allows for backwards
>>>>>>>> compatibility.
>>>>>>>>
>>>>>>>> If you must add keywords it should be something like require_template
>>>>>>>> NOT require_code/require_file. Templates are the exception, not the
>>>>>>>> norm.
>>>>>>>>
>>>>>>>> Luke Scott
>>>>>>>>
>>>>>>>> On Apr 8, 2012, at 9:32 AM, Tom Boutell<[email protected]> wrote:
>>>>>>>>
>>>>>>>>> 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 sure
>>>>>>>>> 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
>>>
>>
>> --
>> 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
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yasuo Ohgaki
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 10:30PM
Hi,


2012/4/10 Stas Malyshev <[email protected]>:
> 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
Stas Malyshev
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 10:40PM
Hi!

> 1. Find FLI vulnerable application.
> 2. Find a way to inject $_SESSION
> 3. Use session file to execute arbitrary PHP code.

So, you assume you have broken application with no security AND it
allows you to inject arbitrary data in the session (which probably means
broken authorization too) and then somehow it's PHP vulnerability? I'm
sorry but this does not make too much sense to me. If you have an
application that allows to execute arbitrary code on external request,
this app has no security. How it is a vulnerability in PHP?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kris Craig
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 10:50PM
Tom,

On Mon, Apr 9, 2012 at 1:20 PM, Yasuo Ohgaki <yohgaki@ohg[email protected]> wrote:

> Hi,
>
>
> 2012/4/10 Stas Malyshev <[email protected]>:
> > 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
Chris Stockton
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 10:50PM
Hello,

2012/4/9 Ángel González <[email protected]>:
> On 09/04/12 20:23, Chris Stockton wrote:
>> Hello,
>> Although I am not very interested in this feature, if it is
>> implemented I like the idea of flags instead of introducing new
>> keywords. Maintaining backwards compatibility would be great
>> considering the benefit to the feature to be completely honest (and in
>> disagreement to many people, but I do understand the reasoning for
>> everyone's interest in it) is extremely minor in my eyes.
>>
>> In addition I would suggest maybe using PHP_INCLUDE_* as a place for
>> these constants to live.
>>
>> -Chris
> That would still be a parse error.
> Either
> include "file.php", 5;
> or
> include ("file.php", 42);
>
> Fails with a parse error about unexpected ','
>
> On the other hand, a new keyword can be written in a backwards
> compatible way by making it look like a function call in a non-taken branch:
>
> *if ( version_compare(PHP_VERSION*, '5.5', '<') )
>  include_once $file;
> else
>  require_code($file, array( 'once'=>true, 'warn' => 'ignore' ) );
>

I am not sure I am following you here Angel, are you confusing
backwards and forward compatibility? I wouldn't expect a feature to
ever work forward compatibly. I.E. Can't use traits in php 4 and can't
play a blu ray disc in a dvd player. The goal here is that if you have
a large code base which has a hand rolled include_code function
already, your change is backwards compatible with that code base. Same
to be said for any constants, which is why I recommended using the
reserved PHP_* space.

-Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rick WIdmer
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 11:00PM
On 4/9/2012 2:41 PM, Kris Craig wrote:
>>
> 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!



Please forget about file extensions. PHP should not consider file
extensions. The only reason .php files are executed by PHP is because
the web browser is configured to pass that extension to PHP rather than
handle it internally.


I sincerely hope that any suggestion to eliminate the ability to use PHP
as a template engine will be met with a veto by the core developers, or
maybe even another suggestion by the trademark owner of PHP that he will
not allow the PHP name to be used on such a language.







--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tom Boutell
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 11:10PM
As others explained before the RFC was drafted, file extensions should
not be directly respected by PHP because environments differ too much.
Instead a convention, NOT enforced at the code level, would be
published and encouraged: .phpc for files that start out in PHP mode,
and .php for files that start out in HTML mode. PHP would NOT enforce
this, it would just be an encouraged practice in the writing of
autoloaders and so on. (Note that autoloaders are already concerned
with file extensions. They have to be in order to transform a class
name into a filename.)

The RFC does not call for putting an end to the traditional use of PHP
for templates at all, that is still the default behavior when parsing
PHP. There is an entirely separate RFC that calls for that, but that's
another thread.

On Mon, Apr 9, 2012 at 4:58 PM, Rick WIdmer <[email protected]> wrote:
> On 4/9/2012 2:41 PM, Kris Craig wrote:
>>>
>>>
>> 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!
>
>
>
>
> Please forget about file extensions.  PHP should not consider file
> extensions.  The only reason .php files are executed by PHP is because the
> web browser is configured to pass that extension to PHP rather than handle
> it internally.
>
>
> I sincerely hope that any suggestion to eliminate the ability to use PHP as
> a template engine will be met with a veto by the core developers, or maybe
> even another suggestion by the trademark owner of PHP that he will not allow
> the PHP name to be used on such a language.
>
>
>
>
>
>
>
>
> --
> 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
Kris Craig
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 11:10PM
On Mon, Apr 9, 2012 at 1:58 PM, Rick WIdmer <[email protected]>wrote:

> On 4/9/2012 2:41 PM, Kris Craig wrote:
>
>>
>>> 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!
>>
>
>
>
> Please forget about file extensions. PHP should not consider file
> extensions. The only reason .php files are executed by PHP is because the
> web browser is configured to pass that extension to PHP rather than handle
> it internally.
>
>
> I sincerely hope that any suggestion to eliminate the ability to use PHP
> as a template engine will be met with a veto by the core developers, or
> maybe even another suggestion by the trademark owner of PHP that he will
> not allow the PHP name to be used on such a language.


That's a bit harsh, don't you think? I mean, it seems a little premature
to be talking about bringing forth IP litigation to stop an RFC that's
still being drafted.

--Kris
Kris Craig
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 11:30PM
On Mon, Apr 9, 2012 at 2:03 PM, Tom Boutell <[email protected]> wrote:

> As others explained before the RFC was drafted, file extensions should
> not be directly respected by PHP because environments differ too much.
> Instead a convention, NOT enforced at the code level, would be
> published and encouraged: .phpc for files that start out in PHP mode,
> and .php for files that start out in HTML mode. PHP would NOT enforce
> this, it would just be an encouraged practice in the writing of
> autoloaders and so on. (Note that autoloaders are already concerned
> with file extensions. They have to be in order to transform a class
> name into a filename.)
>
> The RFC does not call for putting an end to the traditional use of PHP
> for templates at all, that is still the default behavior when parsing
> PHP. There is an entirely separate RFC that calls for that, but that's
> another thread.
>
> On Mon, Apr 9, 2012 at 4:58 PM, Rick WIdmer <[email protected]>
> wrote:
> > On 4/9/2012 2:41 PM, Kris Craig wrote:
> >>>
> >>>
> >> 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!
> >
> >
> >
> >
> > Please forget about file extensions. PHP should not consider file
> > extensions. The only reason .php files are executed by PHP is because
> the
> > web browser is configured to pass that extension to PHP rather than
> handle
> > it internally.
> >
> >
> > I sincerely hope that any suggestion to eliminate the ability to use PHP
> as
> > a template engine will be met with a veto by the core developers, or
> maybe
> > even another suggestion by the trademark owner of PHP that he will not
> allow
> > the PHP name to be used on such a language.
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > 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
>
>
Hmm yeah I see your point. Requiring a separate file extension would force
configuration changes to the webserver. And since not everybody has access
to that, it would mean that any projects that contain these files would not
be able to run on hosts like that.

Ok you've convinced me on the file extension issue, just based on that.
But I still don't like the new require_* keywords or allowing ?> to be
mixed-in with PHP scripts that are supposed to be pure code. Again it just
comes down to a question of usefulness and creating a solution in search of
a problem.

What we need is a way to tell the parser that this file is pure PHP. We
can't use the file extension, so it has to be at the code level. If I'm
interpreting your proposals correctly, it looks like your approach would be
to have the including file make this determination. Personally, I think we
should do the opposite; i.e. this should be defined in the PHP file itself.

Obviously, it would need to be at the top of the PHP file (whitespace
notwithstanding). Since we don't want any BC breaks, we at very least need
it to start with "<?" so that we don't end up parsing anything that wasn't
mean to be parsed. So how about we keep it simple and just use a single,
"<?phpp" at the beginning of the file? No ?> would be allowed after that.
Anything before that (in the file itself) would also be ignored and throw a
warning.

This sounds like the best approach, given the limitations involved with
webserver configurations. I'm still very much against though allowing ?>
within one of these files (included or otherwise), as it really defeats the
whole purpose and would just encourage poor architecture without any
countervailing benefit.

--Kris
Tom Boutell
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 11:30PM
I'm not sure you're wrong about this, but it's definitely an ironic
suggestion (:

On Mon, Apr 9, 2012 at 5:22 PM, Kris Craig <[email protected]> wrote:
>
>
> On Mon, Apr 9, 2012 at 2:03 PM, Tom Boutell <[email protected]> wrote:
>>
>> As others explained before the RFC was drafted, file extensions should
>> not be directly respected by PHP because environments differ too much.
>> Instead a convention, NOT enforced at the code level, would be
>> published and encouraged: .phpc for files that start out in PHP mode,
>> and .php for files that start out in HTML mode. PHP would NOT enforce
>> this, it would just be an encouraged practice in the writing of
>> autoloaders and so on. (Note that autoloaders are already concerned
>> with file extensions. They have to be in order to transform a class
>> name into a filename.)
>>
>> The RFC does not call for putting an end to the traditional use of PHP
>> for templates at all, that is still the default behavior when parsing
>> PHP. There is an entirely separate RFC that calls for that, but that's
>> another thread.
>>
>> On Mon, Apr 9, 2012 at 4:58 PM, Rick WIdmer <[email protected]>
>> wrote:
>> > On 4/9/2012 2:41 PM, Kris Craig wrote:
>> >>>
>> >>>
>> >> 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!
>> >
>> >
>> >
>> >
>> > Please forget about file extensions.  PHP should not consider file
>> > extensions.  The only reason .php files are executed by PHP is because
>> > the
>> > web browser is configured to pass that extension to PHP rather than
>> > handle
>> > it internally.
>> >
>> >
>> > I sincerely hope that any suggestion to eliminate the ability to use PHP
>> > as
>> > a template engine will be met with a veto by the core developers, or
>> > maybe
>> > even another suggestion by the trademark owner of PHP that he will not
>> > allow
>> > the PHP name to be used on such a language.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > 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
>>
>
> Hmm yeah I see your point.  Requiring a separate file extension would force
> configuration changes to the webserver.  And since not everybody has access
> to that, it would mean that any projects that contain these files would not
> be able to run on hosts like that.
>
> Ok you've convinced me on the file extension issue, just based on that.  But
> I still don't like the new require_* keywords or allowing ?> to be mixed-in
> with PHP scripts that are supposed to be pure code.  Again it just comes
> down to a question of usefulness and creating a solution in search of a
> problem.
>
> What we need is a way to tell the parser that this file is pure PHP.  We
> can't use the file extension, so it has to be at the code level.  If I'm
> interpreting your proposals correctly, it looks like your approach would be
> to have the including file make this determination.  Personally, I think we
> should do the opposite; i.e. this should be defined in the PHP file itself.
>
> Obviously, it would need to be at the top of the PHP file (whitespace
> notwithstanding).  Since we don't want any BC breaks, we at very least need
> it to start with "<?" so that we don't end up parsing anything that wasn't
> mean to be parsed.  So how about we keep it simple and just use a single,
> "<?phpp" at the beginning of the file?  No ?> would be allowed after that.
> Anything before that (in the file itself) would also be ignored and throw a
> warning.
>
> This sounds like the best approach, given the limitations involved with
> webserver configurations.  I'm still very much against though allowing ?>
> within one of these files (included or otherwise), as it really defeats the
> whole purpose and would just encourage poor architecture without any
> countervailing benefit.
>
> --Kris
>



--
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
Kris Craig
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 11:40PM
Lol true dat. You convinced me on the file extension, so as far as I can
tell that just leaves us with the tag itself as the viable approach. =)

--Kris


On Mon, Apr 9, 2012 at 2:24 PM, Tom Boutell <[email protected]> wrote:

> I'm not sure you're wrong about this, but it's definitely an ironic
> suggestion (:
>
> On Mon, Apr 9, 2012 at 5:22 PM, Kris Craig <[email protected]> wrote:
> >
> >
> > On Mon, Apr 9, 2012 at 2:03 PM, Tom Boutell <[email protected]> wrote:
> >>
> >> As others explained before the RFC was drafted, file extensions should
> >> not be directly respected by PHP because environments differ too much.
> >> Instead a convention, NOT enforced at the code level, would be
> >> published and encouraged: .phpc for files that start out in PHP mode,
> >> and .php for files that start out in HTML mode. PHP would NOT enforce
> >> this, it would just be an encouraged practice in the writing of
> >> autoloaders and so on. (Note that autoloaders are already concerned
> >> with file extensions. They have to be in order to transform a class
> >> name into a filename.)
> >>
> >> The RFC does not call for putting an end to the traditional use of PHP
> >> for templates at all, that is still the default behavior when parsing
> >> PHP. There is an entirely separate RFC that calls for that, but that's
> >> another thread.
> >>
> >> On Mon, Apr 9, 2012 at 4:58 PM, Rick WIdmer <[email protected]>
> >> wrote:
> >> > On 4/9/2012 2:41 PM, Kris Craig wrote:
> >> >>>
> >> >>>
> >> >> 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!
> >> >
> >> >
> >> >
> >> >
> >> > Please forget about file extensions. PHP should not consider file
> >> > extensions. The only reason .php files are executed by PHP is because
> >> > the
> >> > web browser is configured to pass that extension to PHP rather than
> >> > handle
> >> > it internally.
> >> >
> >> >
> >> > I sincerely hope that any suggestion to eliminate the ability to use
> PHP
> >> > as
> >> > a template engine will be met with a veto by the core developers, or
> >> > maybe
> >> > even another suggestion by the trademark owner of PHP that he will not
> >> > allow
> >> > the PHP name to be used on such a language.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > 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
> >>
> >
> > Hmm yeah I see your point. Requiring a separate file extension would
> force
> > configuration changes to the webserver. And since not everybody has
> access
> > to that, it would mean that any projects that contain these files would
> not
> > be able to run on hosts like that.
> >
> > Ok you've convinced me on the file extension issue, just based on that.
> But
> > I still don't like the new require_* keywords or allowing ?> to be
> mixed-in
> > with PHP scripts that are supposed to be pure code. Again it just comes
> > down to a question of usefulness and creating a solution in search of a
> > problem.
> >
> > What we need is a way to tell the parser that this file is pure PHP. We
> > can't use the file extension, so it has to be at the code level. If I'm
> > interpreting your proposals correctly, it looks like your approach would
> be
> > to have the including file make this determination. Personally, I think
> we
> > should do the opposite; i.e. this should be defined in the PHP file
> itself.
> >
> > Obviously, it would need to be at the top of the PHP file (whitespace
> > notwithstanding). Since we don't want any BC breaks, we at very least
> need
> > it to start with "<?" so that we don't end up parsing anything that
> wasn't
> > mean to be parsed. So how about we keep it simple and just use a single,
> > "<?phpp" at the beginning of the file? No ?> would be allowed after
> that.
> > Anything before that (in the file itself) would also be ignored and
> throw a
> > warning.
> >
> > This sounds like the best approach, given the limitations involved with
> > webserver configurations. I'm still very much against though allowing ?>
> > within one of these files (included or otherwise), as it really defeats
> the
> > whole purpose and would just encourage poor architecture without any
> > countervailing benefit.
> >
> > --Kris
> >
>
>
>
> --
> 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
>
>
Luke Scott
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 11:40PM
> Obviously, it would need to be at the top of the PHP file (whitespace
> notwithstanding). Since we don't want any BC breaks, we at very least need
> it to start with "<?" so that we don't end up parsing anything that wasn't
> mean to be parsed. So how about we keep it simple and just use a single,
> "<?phpp" at the beginning of the file? No ?> would be allowed after that.
> Anything before that (in the file itself) would also be ignored and throw a
> warning.

Remember, <?xml tags. I think <? By itself was deprecated for this reason.

> This sounds like the best approach, given the limitations involved with
> webserver configurations. I'm still very much against though allowing ?>
> within one of these files (included or otherwise), as it really defeats the
> whole purpose and would just encourage poor architecture without any
> countervailing benefit.

Agreed. Disallowing ?> in a file in pure code means only one <?php tag
at the top.

A flag on require/include is acceptable to me, as long as the default
mode is configurable in the php.ini file (when none are specified).

Luke

>
> --Kris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kris Craig
Re: [PHP-DEV] RFC: source files without opening tag
April 10, 2012 12:10AM
On Mon, Apr 9, 2012 at 2:38 PM, Luke Scott <[email protected]> wrote:

> > Obviously, it would need to be at the top of the PHP file (whitespace
> > notwithstanding). Since we don't want any BC breaks, we at very least
> need
> > it to start with "<?" so that we don't end up parsing anything that
> wasn't
> > mean to be parsed. So how about we keep it simple and just use a single,
> > "<?phpp" at the beginning of the file? No ?> would be allowed after
> that.
> > Anything before that (in the file itself) would also be ignored and
> throw a
> > warning.
>
> Remember, <?xml tags. I think <? By itself was deprecated for this reason.
>

Bah, right! That damned <?xml tag....

I already know what everyone's reaction will be, and it is probably a
REALLY bad idea, but I feel obligated to at least mention it: Should we
consider replacing "<?..." with something that doesn't conflict with
anything, perhaps starting in PHP 6? No need to get out the torches and
pitchforks, everyone! As insane and problematic as that would be (i.e. BC
break with roughly 1/3 of the internet lol), I felt as though the subject
should at least be broached. ;P


>
> > This sounds like the best approach, given the limitations involved with
> > webserver configurations. I'm still very much against though allowing ?>
> > within one of these files (included or otherwise), as it really defeats
> the
> > whole purpose and would just encourage poor architecture without any
> > countervailing benefit.
>
> Agreed. Disallowing ?> in a file in pure code means only one <?php tag
> at the top.
>

> A flag on require/include is acceptable to me, as long as the default
> mode is configurable in the php.ini file (when none are specified).
>

Perhaps we should split that into a separate RFC? I.e. a require flag that
tells it to parse the included PHP file as pure PHP, regardless of whether
or not it has the <?phpp tag. I'm not sure if this would be
workable/necessary or not, but it's different enough that I think splitting
it off into a separate proposal would probably make the most sense.


>
> Luke
>
> >
> > --Kris
>
Tom Boutell
Re: [PHP-DEV] RFC: source files without opening tag
April 10, 2012 12:20AM
My original goal was to stop typing <?php in pure code files. That
includes at the top. I think it's entirely reasonable to achieve it
with an option to the require keywords for this purpose and a naming
convention to be followed by autoloaders. Keep in mind how rarely you
have to change them. We're talking about code maintained by a
relatively small number of very sharp developers. They can handle a
few flags (:

The prohibition of ?> still seems unnecessary and perhaps divisive,
but if it were preferable to the majority to prohibit ?> in a pure
code file, I could live with that as long as classic PHP files are
also 100% supported and remain the default. I'm trying to craft a
broadly acceptable compromise that still achieves the original goal of
allowing people to write "just code" in a class file.

On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig <[email protected]> wrote:
>
>
> On Mon, Apr 9, 2012 at 2:38 PM, Luke Scott <[email protected]> wrote:
>>
>> > Obviously, it would need to be at the top of the PHP file (whitespace
>> > notwithstanding).  Since we don't want any BC breaks, we at very least
>> > need
>> > it to start with "<?" so that we don't end up parsing anything that
>> > wasn't
>> > mean to be parsed.  So how about we keep it simple and just use a
>> > single,
>> > "<?phpp" at the beginning of the file?  No ?> would be allowed after
>> > that.
>> > Anything before that (in the file itself) would also be ignored and
>> > throw a
>> > warning.
>>
>> Remember, <?xml tags. I think <? By itself was deprecated for this reason.
>
>
> Bah, right!  That damned <?xml tag....
>
> I already know what everyone's reaction will be, and it is probably a REALLY
> bad idea, but I feel obligated to at least mention it:  Should we consider
> replacing "<?..." with something that doesn't conflict with anything,
> perhaps starting in PHP 6?  No need to get out the torches and pitchforks,
> everyone!  As insane and problematic as that would be (i.e. BC break with
> roughly 1/3 of the internet lol), I felt as though the subject should at
> least be broached.  ;P
>
>>
>>
>> > This sounds like the best approach, given the limitations involved with
>> > webserver configurations.  I'm still very much against though allowing
>> > ?>
>> > within one of these files (included or otherwise), as it really defeats
>> > the
>> > whole purpose and would just encourage poor architecture without any
>> > countervailing benefit.
>>
>> Agreed. Disallowing ?> in a file in pure code means only one <?php tag
>> at the top.
>>
>>
>> A flag on require/include is acceptable to me, as long as the default
>> mode is configurable in the php.ini file (when none are specified).
>
>
> Perhaps we should split that into a separate RFC?  I.e. a require flag that
> tells it to parse the included PHP file as pure PHP, regardless of whether
> or not it has the <?phpp tag.  I'm not sure if this would be
> workable/necessary or not, but it's different enough that I think splitting
> it off into a separate proposal would probably make the most sense.
>
>>
>>
>> Luke
>>
>> >
>> > --Kris
>
>



--
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
Luke Scott
Re: [PHP-DEV] RFC: source files without opening tag
April 10, 2012 12:40AM
Tom,

On 4/9/12 3:17 PM, "Tom Boutell" <[email protected]> wrote:

>My original goal was to stop typing <?php in pure code files. That
>includes at the top. I think it's entirely reasonable to achieve it
>with an option to the require keywords for this purpose and a naming
>convention to be followed by autoloaders. Keep in mind how rarely you
>have to change them. We're talking about code maintained by a
>relatively small number of very sharp developers. They can handle a
>few flags (:
>
>The prohibition of ?> still seems unnecessary and perhaps divisive,
>but if it were preferable to the majority to prohibit ?> in a pure
>code file, I could live with that as long as classic PHP files are
>also 100% supported and remain the default. I'm trying to craft a
>broadly acceptable compromise that still achieves the original goal of
>allowing people to write "just code" in a class file.


I think you can you achieve that by making "template mode" default and the
default changeable in the php.ini file.

Something like this:

/*
Code only, <?php at top optional, no ?>.
Text before opening <?php silently dropped

*/

require "/path/to/somefile.php", INCLUDE_CODE;

/*
Works exactly as it is now: <?php and ?> allowed.
Text betweeen ?>...<?php printed to output buffer.
*/



require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now

/*
By default INCLUDE_TEMPLATE
Can change default mode in php.ini to be INCLUDE_CODE if desired.
*/

require "/path/to/anotherfile.php"; // As it is now


Personally I would like to be able to do something like this in my auto
loader:

include $file, INCLUDE_CODE & INCLUDE_SILENT;



That way I can ensure pure code is being inserted and no warnings are
thrown if the file doesn't exist (class undefined will be thrown anyway).

I think it's important to make <?php optional at the top if you're using
existing or third party libraries that you can't modify. At least then
you'll be able to maintain backwards compatibility with most code written
since PHP 5.

(We don't need PHP_*. See the output of get_defined_constants() ).

I like where this is going! Hopefully after the RFC has been finalized
everyone else will agree.


>
>On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig <[email protected]> wrote:


Kris,



>>
>>
>> Bah, right! That damned <?xml tag....
>>
>> I already know what everyone's reaction will be, and it is probably a
>>REALLY
>> bad idea, but I feel obligated to at least mention it: Should we
>>consider
>> replacing "<?..." with something that doesn't conflict with anything,
>> perhaps starting in PHP 6? No need to get out the torches and
>>pitchforks,
>> everyone! As insane and problematic as that would be (i.e. BC break
>>with
>> roughly 1/3 of the internet lol), I felt as though the subject should at
>> least be broached. ;P


No need. Just keep it as <?php. It's already been well established. We
should ovoid overcomplicating it.

Luke



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tom Boutell
Re: [PHP-DEV] RFC: source files without opening tag
April 10, 2012 01:00AM
I see why you want to allow <?php at the top to be optional in 'code
mode,' rather than disallowed in code mode. But your purpose is to
allow legacy code to be autoloaded without knowing in advance whether
it starts with <?php or not.

But that would probably lead in practice to the use of a single file
extension for old and new class files.

And that, in turn, would lead to source code being spewed to the
browser for all to see if a perfectly respectable autoloader circa PHP
5.3 runs into one of these new files.

This is a much more significant security issue than some of those
mentioned previously because perfectly well-written code would display
this behavior if someone unknowingly drops a newer library into, say,
the lib/ folder of a Symfony 1.4 project. Ouch.

It would be much better for that autoloader to just ignore the file
because it has a new extension. This way the problem is immediately
apparent:

"Hey, my class didn't load, something must be up. Oh my PHP is old
and/or this autoloader doesn't know about .phpc files, what are they
anyway... google google... aha, I need PHP 5.x and an updated
autoloader. Grumble. Okay."

This is a much safer outcome.

On Mon, Apr 9, 2012 at 6:34 PM, Luke Scott <[email protected]> wrote:
> Tom,
>
> On 4/9/12 3:17 PM, "Tom Boutell" <[email protected]> wrote:
>
>>My original goal was to stop typing <?php in pure code files. That
>>includes at the top. I think it's entirely reasonable to achieve it
>>with an option to the require keywords for this purpose and a naming
>>convention to be followed by autoloaders. Keep in mind how rarely you
>>have to change them. We're talking about code maintained by a
>>relatively small number of very sharp developers. They can handle a
>>few flags (:
>>
>>The prohibition of ?> still seems unnecessary and perhaps divisive,
>>but if it were preferable to the majority to prohibit ?> in a pure
>>code file, I could live with that as long as classic PHP files are
>>also 100% supported and remain the default. I'm trying to craft a
>>broadly acceptable compromise that still achieves the original goal of
>>allowing people to write "just code" in a class file.
>
>
> I think you can you achieve that by making "template mode" default and the
> default changeable in the php.ini file.
>
> Something like this:
>
> /*
>    Code only, <?php at top optional, no ?>.
>    Text before opening <?php silently dropped
>
> */
>
> require "/path/to/somefile.php", INCLUDE_CODE;
>
> /*
>    Works exactly as it is now: <?php and ?> allowed.
>    Text betweeen ?>...<?php printed to output buffer.
> */
>
>
>
> require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now
>
> /*
>    By default INCLUDE_TEMPLATE
>    Can change default mode in php.ini to be INCLUDE_CODE if desired.
> */
>
> require "/path/to/anotherfile.php"; // As it is now
>
>
> Personally I would like to be able to do something like this in my auto
> loader:
>
> include $file, INCLUDE_CODE & INCLUDE_SILENT;
>
>
>
> That way I can ensure pure code is being inserted and no warnings are
> thrown if the file doesn't exist (class undefined will be thrown anyway).
>
> I think it's important to make <?php optional at the top if you're using
> existing or third party libraries that you can't modify. At least then
> you'll be able to maintain backwards compatibility with most code written
> since PHP 5.
>
> (We don't need PHP_*. See the output of get_defined_constants() ).
>
> I like where this is going! Hopefully after the RFC has been finalized
> everyone else will agree.
>
>
>>
>>On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig <[email protected]> wrote:
>
>
> Kris,
>
>
>
>>>
>>>
>>> Bah, right!  That damned <?xml tag....
>>>
>>> I already know what everyone's reaction will be, and it is probably a
>>>REALLY
>>> bad idea, but I feel obligated to at least mention it:  Should we
>>>consider
>>> replacing "<?..." with something that doesn't conflict with anything,
>>> perhaps starting in PHP 6?  No need to get out the torches and
>>>pitchforks,
>>> everyone!  As insane and problematic as that would be (i.e. BC break
>>>with
>>> roughly 1/3 of the internet lol), I felt as though the subject should at
>>> least be broached.  ;P
>
>
> No need. Just keep it as <?php. It's already been well established. We
> should ovoid overcomplicating it.
>
> Luke
>
>



--
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
Kris Craig
Re: [PHP-DEV] RFC: source files without opening tag
April 10, 2012 01:00AM
On Mon, Apr 9, 2012 at 3:34 PM, Luke Scott <[email protected]> wrote:

> Tom,
>
> On 4/9/12 3:17 PM, "Tom Boutell" <[email protected]> wrote:
>
> >My original goal was to stop typing <?php in pure code files. That
> >includes at the top. I think it's entirely reasonable to achieve it
> >with an option to the require keywords for this purpose and a naming
> >convention to be followed by autoloaders. Keep in mind how rarely you
> >have to change them. We're talking about code maintained by a
> >relatively small number of very sharp developers. They can handle a
> >few flags (:
>

Again though, the problem here is that you're relying on the
*including*script to determine whether a PHP script is pure or not;
i.e. this approach
leaves no way for that to be determined in the file itself. For example, I
can see perfectly valid instances where it would be ideal to execute one of
these pure scripts as a direct call to the webserver-- AJAX being a prime
example. I.e. cases where you want backend PHP processing to take place
but it has to be accessed via the browser (most likely "hidden" as an AJAX
query though).

So without the ability to do that, I just don't think this passes the
usefulness test for me. And if we do have the ability to specify that in
the file, on the other hand, then that would pretty much eliminate the need
for a require flag anyway.

The only alternative I can see would be to allow something to be passed in
the headers telling the webserver to parse a script as PHP instead of
HTML. But I don't know if that would be extremely simple or extremely
problematic.

--Kris



> >
> >The prohibition of ?> still seems unnecessary and perhaps divisive,
> >but if it were preferable to the majority to prohibit ?> in a pure
> >code file, I could live with that as long as classic PHP files are
> >also 100% supported and remain the default. I'm trying to craft a
> >broadly acceptable compromise that still achieves the original goal of
> >allowing people to write "just code" in a class file.
>
>
> I think you can you achieve that by making "template mode" default and the
> default changeable in the php.ini file.
>
> Something like this:
>
> /*
> Code only, <?php at top optional, no ?>.
> Text before opening <?php silently dropped
>
> */
>
> require "/path/to/somefile.php", INCLUDE_CODE;
>
> /*
> Works exactly as it is now: <?php and ?> allowed.
> Text betweeen ?>...<?php printed to output buffer.
> */
>
>
>
> require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now
>
> /*
> By default INCLUDE_TEMPLATE
> Can change default mode in php.ini to be INCLUDE_CODE if desired.
> */
>
> require "/path/to/anotherfile.php"; // As it is now
>
>
> Personally I would like to be able to do something like this in my auto
> loader:
>
> include $file, INCLUDE_CODE & INCLUDE_SILENT;
>
>
>
> That way I can ensure pure code is being inserted and no warnings are
> thrown if the file doesn't exist (class undefined will be thrown anyway).
>
> I think it's important to make <?php optional at the top if you're using
> existing or third party libraries that you can't modify. At least then
> you'll be able to maintain backwards compatibility with most code written
> since PHP 5.
>
> (We don't need PHP_*. See the output of get_defined_constants() ).
>
> I like where this is going! Hopefully after the RFC has been finalized
> everyone else will agree.
>
>
> >
> >On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig <[email protected]> wrote:
>
>
> Kris,
>
>
>
> >>
> >>
> >> Bah, right! That damned <?xml tag....
> >>
> >> I already know what everyone's reaction will be, and it is probably a
> >>REALLY
> >> bad idea, but I feel obligated to at least mention it: Should we
> >>consider
> >> replacing "<?..." with something that doesn't conflict with anything,
> >> perhaps starting in PHP 6? No need to get out the torches and
> >>pitchforks,
> >> everyone! As insane and problematic as that would be (i.e. BC break
> >>with
> >> roughly 1/3 of the internet lol), I felt as though the subject should at
> >> least be broached. ;P
>
>
> No need. Just keep it as <?php. It's already been well established. We
> should ovoid overcomplicating it.
>
> Luke
>
>
>
Luke Scott
Re: [PHP-DEV] RFC: source files without opening tag
April 10, 2012 01:10AM
On 4/9/12 3:53 PM, "Tom Boutell" <[email protected]> wrote:

>I see why you want to allow <?php at the top to be optional in 'code
>mode,' rather than disallowed in code mode. But your purpose is to
>allow legacy code to be autoloaded without knowing in advance whether
>it starts with <?php or not.
>
>But that would probably lead in practice to the use of a single file
>extension for old and new class files.
>
>And that, in turn, would lead to source code being spewed to the
>browser for all to see if a perfectly respectable autoloader circa PHP
>5.3 runs into one of these new files.
>
>This is a much more significant security issue than some of those
>mentioned previously because perfectly well-written code would display
>this behavior if someone unknowingly drops a newer library into, say,
>the lib/ folder of a Symfony 1.4 project. Ouch.


So are you saying the starting "<?php" tag should be required in "code
mode"?

If so, I'm ok with that as long as:

- "?>" is forbidden

- Text before the opening <?php tag (literal text or white-spaces) is
either ignored or throws an error instead of printing to the output buffer.

If that's not what you mean, please clarify.

Luke

>
>It would be much better for that autoloader to just ignore the file
>because it has a new extension. This way the problem is immediately
>apparent:
>
>"Hey, my class didn't load, something must be up. Oh my PHP is old
>and/or this autoloader doesn't know about .phpc files, what are they
>anyway... google google... aha, I need PHP 5.x and an updated
>autoloader. Grumble. Okay."
>
>This is a much safer outcome.
>
>On Mon, Apr 9, 2012 at 6:34 PM, Luke Scott <[email protected]> wrote:
>> Tom,
>>
>> On 4/9/12 3:17 PM, "Tom Boutell" <[email protected]> wrote:
>>
>>>My original goal was to stop typing <?php in pure code files. That
>>>includes at the top. I think it's entirely reasonable to achieve it
>>>with an option to the require keywords for this purpose and a naming
>>>convention to be followed by autoloaders. Keep in mind how rarely you
>>>have to change them. We're talking about code maintained by a
>>>relatively small number of very sharp developers. They can handle a
>>>few flags (:
>>>
>>>The prohibition of ?> still seems unnecessary and perhaps divisive,
>>>but if it were preferable to the majority to prohibit ?> in a pure
>>>code file, I could live with that as long as classic PHP files are
>>>also 100% supported and remain the default. I'm trying to craft a
>>>broadly acceptable compromise that still achieves the original goal of
>>>allowing people to write "just code" in a class file.
>>
>>
>> I think you can you achieve that by making "template mode" default and
>>the
>> default changeable in the php.ini file.
>>
>> Something like this:
>>
>> /*
>> Code only, <?php at top optional, no ?>.
>> Text before opening <?php silently dropped
>>
>> */
>>
>> require "/path/to/somefile.php", INCLUDE_CODE;
>>
>> /*
>> Works exactly as it is now: <?php and ?> allowed.
>> Text betweeen ?>...<?php printed to output buffer.
>> */
>>
>>
>>
>> require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now
>>
>> /*
>> By default INCLUDE_TEMPLATE
>> Can change default mode in php.ini to be INCLUDE_CODE if desired.
>> */
>>
>> require "/path/to/anotherfile.php"; // As it is now
>>
>>
>> Personally I would like to be able to do something like this in my auto
>> loader:
>>
>> include $file, INCLUDE_CODE & INCLUDE_SILENT;
>>
>>
>>
>> That way I can ensure pure code is being inserted and no warnings are
>> thrown if the file doesn't exist (class undefined will be thrown
>>anyway).
>>
>> I think it's important to make <?php optional at the top if you're using
>> existing or third party libraries that you can't modify. At least then
>> you'll be able to maintain backwards compatibility with most code
>>written
>> since PHP 5.
>>
>> (We don't need PHP_*. See the output of get_defined_constants() ).
>>
>> I like where this is going! Hopefully after the RFC has been finalized
>> everyone else will agree.
>>
>>
>>>
>>>On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig <[email protected]> wrote:
>>
>>
>> Kris,
>>
>>
>>
>>>>
>>>>
>>>> Bah, right! That damned <?xml tag....
>>>>
>>>> I already know what everyone's reaction will be, and it is probably a
>>>>REALLY
>>>> bad idea, but I feel obligated to at least mention it: Should we
>>>>consider
>>>> replacing "<?..." with something that doesn't conflict with anything,
>>>> perhaps starting in PHP 6? No need to get out the torches and
>>>>pitchforks,
>>>> everyone! As insane and problematic as that would be (i.e. BC break
>>>>with
>>>> roughly 1/3 of the internet lol), I felt as though the subject should
>>>>at
>>>> least be broached. ;P
>>
>>
>> No need. Just keep it as <?php. It's already been well established. We
>> should ovoid overcomplicating it.
>>
>> Luke
>>
>>
>
>
>
>--
>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
>



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Luke Scott
Re: [PHP-DEV] RFC: source files without opening tag
April 10, 2012 01:10AM
> On Mon, Apr 9, 2012 at 3:34 PM, Luke Scott <[email protected]> wrote:
>> Tom,
>>
>> On 4/9/12 3:17 PM, "Tom Boutell" <[email protected]> wrote:
>>
>>> >My original goal was to stop typing <?php in pure code files. That
>>> >includes at the top. I think it's entirely reasonable to achieve it
>>> >with an option to the require keywords for this purpose and a naming
>>> >convention to be followed by autoloaders. Keep in mind how rarely you
>>> >have to change them. We're talking about code maintained by a
>>> >relatively small number of very sharp developers. They can handle a
>>> >few flags (:
>
> Again though, the problem here is that you're relying on the including script
> to determine whether a PHP script is pure or not; i.e. this approach leaves no
> way for that to be determined in the file itself. For example, I can see
> perfectly valid instances where it would be ideal to execute one of these pure
> scripts as a direct call to the webserver-- AJAX being a prime example. I.e.
> cases where you want backend PHP processing to take place but it has to be
> accessed via the browser (most likely "hidden" as an AJAX query though).
>
> So without the ability to do that, I just don't think this passes the
> usefulness test for me. And if we do have the ability to specify that in the
> file, on the other hand, then that would pretty much eliminate the need for a
> require flag anyway.
>
> The only alternative I can see would be to allow something to be passed in the
> headers telling the webserver to parse a script as PHP instead of HTML. But I
> don't know if that would be extremely simple or extremely problematic.

If the default mode was configured in the php.ini file (code mode vs
template mode) wouldn't the web server use that?

The web server is pretty much doing this: require "/path/to/somefile.php".

Luke

>
>
> --Kris
>
>
>>> >
>>> >The prohibition of ?> still seems unnecessary and perhaps divisive,
>>> >but if it were preferable to the majority to prohibit ?> in a pure
>>> >code file, I could live with that as long as classic PHP files are
>>> >also 100% supported and remain the default. I'm trying to craft a
>>> >broadly acceptable compromise that still achieves the original goal of
>>> >allowing people to write "just code" in a class file.
>>
>>
>> I think you can you achieve that by making "template mode" default and the
>> default changeable in the php.ini file.
>>
>> Something like this:
>>
>> /*
>> Code only, <?php at top optional, no ?>.
>> Text before opening <?php silently dropped
>>
>> */
>>
>> require "/path/to/somefile.php", INCLUDE_CODE;
>>
>> /*
>> Works exactly as it is now: <?php and ?> allowed.
>> Text betweeen ?>...<?php printed to output buffer.
>> */
>>
>>
>>
>> require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now
>>
>> /*
>> By default INCLUDE_TEMPLATE
>> Can change default mode in php.ini to be INCLUDE_CODE if desired.
>> */
>>
>> require "/path/to/anotherfile.php"; // As it is now
>>
>>
>> Personally I would like to be able to do something like this in my auto
>> loader:
>>
>> include $file, INCLUDE_CODE & INCLUDE_SILENT;
>>
>>
>>
>> That way I can ensure pure code is being inserted and no warnings are
>> thrown if the file doesn't exist (class undefined will be thrown anyway).
>>
>> I think it's important to make <?php optional at the top if you're using
>> existing or third party libraries that you can't modify. At least then
>> you'll be able to maintain backwards compatibility with most code written
>> since PHP 5.
>>
>> (We don't need PHP_*. See the output of get_defined_constants() ).
>>
>> I like where this is going! Hopefully after the RFC has been finalized
>> everyone else will agree.
>>
>>
>>> >
>>> >On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig <[email protected]> wrote:
>>
>>
>> Kris,
>>
>>
>>
>>>> >>
>>>> >>
>>>> >> Bah, right! That damned <?xml tag....
>>>> >>
>>>> >> I already know what everyone's reaction will be, and it is probably a
>>>> >>REALLY
>>>> >> bad idea, but I feel obligated to at least mention it: Should we
>>>> >>consider
>>>> >> replacing "<?..." with something that doesn't conflict with anything,
>>>> >> perhaps starting in PHP 6? No need to get out the torches and
>>>> >>pitchforks,
>>>> >> everyone! As insane and problematic as that would be (i.e. BC break
>>>> >>with
>>>> >> roughly 1/3 of the internet lol), I felt as though the subject should at
>>>> >> least be broached. ;P
>>
>>
>> No need. Just keep it as <?php. It's already been well established. We
>> should ovoid overcomplicating it.
>>
>> Luke
>>
>>
>
Yasuo Ohgaki
Re: [PHP-DEV] RFC: source files without opening tag
April 10, 2012 01:40AM
Hi,

2012/4/10 Stas Malyshev <[email protected]>:
> Hi!
>
>> 1. Find FLI vulnerable application.
>> 2. Find a way to inject $_SESSION
>> 3. Use session file to execute arbitrary PHP code.
>
> So, you assume you have broken application with no security AND it
> allows you to inject arbitrary data in the session (which probably means
> broken authorization too) and then somehow it's PHP vulnerability? I'm
> sorry but this does not make too much sense to me. If you have an
> application that allows to execute arbitrary code on external request,
> this app has no security. How it is a vulnerability in PHP?

It's a design vulnerability. It is not has to be attack-able security hole
without broken code. There are many security issues and countermeasure
like this. e.g. register globals in PHP, stack smashing attack in C, etc.

Some people are trying to introduce TAG less execution. Wise choice for
TAG less execution would be removing famous LFI vulnerability from PHP.

Regards,

P.S. BTW, LFI is not only good for execution, but also information disclosure.
Just is case, people on this thread didn't realize it.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tom Boutell
Re: [PHP-DEV] RFC: source files without opening tag
April 10, 2012 01:50AM
On Mon, Apr 9, 2012 at 6:54 PM, Kris Craig <[email protected]> wrote:
> Again though, the problem here is that you're relying on the including
> script to determine whether a PHP script is pure or not; i.e. this approach
> leaves no way for that to be determined in the file itself.  For example, I
> can see perfectly valid instances where it would be ideal to execute one of
> these pure scripts as a direct call to the webserver-- AJAX being a prime
> example.  I.e. cases where you want backend PHP processing to take place but
> it has to be accessed via the browser (most likely "hidden" as an AJAX query
> though).

As others have pointed out, the proposal could be amended to include
options for the CGI, FPM, etc. SAPIs so that Apache and other servers
could be configured to recognize a specific file extension as starting
out in code mode, if desired. The CLI SAPI could have an option too.
I'm not opposed, I just don't feel as strong a need for it because I
normally write framework code that uses autoloaded classes, not
standalone directly accessed scripts. This would address your concern
without hardcoding file extensions into PHP itself.

The rest of your comments are pretty close to alterations I plan to
make to the RFC.

--
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
Re: [PHP-DEV] RFC: source files without opening tag
April 10, 2012 01:50AM
Let me be very clear about that... I am NOT proposing that <?php at
the top be mandatory in a file loaded in code mode! I don't want to
type it ever again outside of a template file, personally. See the
title of the RFC.

On Mon, Apr 9, 2012 at 7:06 PM, Luke Scott <[email protected]> wrote:
> On 4/9/12 3:53 PM, "Tom Boutell" <[email protected]> wrote:
>
>>I see why you want to allow <?php at the top to be optional in 'code
>>mode,' rather than disallowed in code mode. But your purpose is to
>>allow legacy code to be autoloaded without knowing in advance whether
>>it starts with <?php or not.
>>
>>But that would probably lead in practice to the use of a single file
>>extension for old and new class files.
>>
>>And that, in turn, would lead to source code being spewed to the
>>browser for all to see if a perfectly respectable autoloader circa PHP
>>5.3 runs into one of these new files.
>>
>>This is a much more significant security issue than some of those
>>mentioned previously because perfectly well-written code would display
>>this behavior if someone unknowingly drops a newer library into, say,
>>the lib/ folder of a Symfony 1.4 project. Ouch.
>
>
> So are you saying the starting "<?php" tag should be required in "code
> mode"?
>
> If so, I'm ok with that as long as:
>
> - "?>" is forbidden
>
> - Text before the opening <?php tag (literal text or white-spaces) is
> either ignored or throws an error instead of printing to the output buffer.
>
> If that's not what you mean, please clarify.
>
> Luke
>
>>
>>It would be much better for that autoloader to just ignore the file
>>because it has a new extension. This way the problem is immediately
>>apparent:
>>
>>"Hey, my class didn't load, something must be up. Oh my PHP is old
>>and/or this autoloader doesn't know about .phpc files, what are they
>>anyway... google google... aha, I need PHP 5.x and an updated
>>autoloader. Grumble. Okay."
>>
>>This is a much safer outcome.
>>
>>On Mon, Apr 9, 2012 at 6:34 PM, Luke Scott <[email protected]> wrote:
>>> Tom,
>>>
>>> On 4/9/12 3:17 PM, "Tom Boutell" <[email protected]> wrote:
>>>
>>>>My original goal was to stop typing <?php in pure code files. That
>>>>includes at the top. I think it's entirely reasonable to achieve it
>>>>with an option to the require keywords for this purpose and a naming
>>>>convention to be followed by autoloaders. Keep in mind how rarely you
>>>>have to change them. We're talking about code maintained by a
>>>>relatively small number of very sharp developers. They can handle a
>>>>few flags (:
>>>>
>>>>The prohibition of ?> still seems unnecessary and perhaps divisive,
>>>>but if it were preferable to the majority to prohibit ?> in a pure
>>>>code file, I could live with that as long as classic PHP files are
>>>>also 100% supported and remain the default. I'm trying to craft a
>>>>broadly acceptable compromise that still achieves the original goal of
>>>>allowing people to write "just code" in a class file.
>>>
>>>
>>> I think you can you achieve that by making "template mode" default and
>>>the
>>> default changeable in the php.ini file.
>>>
>>> Something like this:
>>>
>>> /*
>>>    Code only, <?php at top optional, no ?>.
>>>    Text before opening <?php silently dropped
>>>
>>> */
>>>
>>> require "/path/to/somefile.php", INCLUDE_CODE;
>>>
>>> /*
>>>    Works exactly as it is now: <?php and ?> allowed.
>>>    Text betweeen ?>...<?php printed to output buffer.
>>> */
>>>
>>>
>>>
>>> require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now
>>>
>>> /*
>>>    By default INCLUDE_TEMPLATE
>>>    Can change default mode in php.ini to be INCLUDE_CODE if desired..
>>> */
>>>
>>> require "/path/to/anotherfile.php"; // As it is now
>>>
>>>
>>> Personally I would like to be able to do something like this in my auto
>>> loader:
>>>
>>> include $file, INCLUDE_CODE & INCLUDE_SILENT;
>>>
>>>
>>>
>>> That way I can ensure pure code is being inserted and no warnings are
>>> thrown if the file doesn't exist (class undefined will be thrown
>>>anyway).
>>>
>>> I think it's important to make <?php optional at the top if you're using
>>> existing or third party libraries that you can't modify. At least then
>>> you'll be able to maintain backwards compatibility with most code
>>>written
>>> since PHP 5.
>>>
>>> (We don't need PHP_*. See the output of get_defined_constants() ).
>>>
>>> I like where this is going! Hopefully after the RFC has been finalized
>>> everyone else will agree.
>>>
>>>
>>>>
>>>>On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig <[email protected]> wrote:
>>>
>>>
>>> Kris,
>>>
>>>
>>>
>>>>>
>>>>>
>>>>> Bah, right!  That damned <?xml tag....
>>>>>
>>>>> I already know what everyone's reaction will be, and it is probably a
>>>>>REALLY
>>>>> bad idea, but I feel obligated to at least mention it:  Should we
>>>>>consider
>>>>> replacing "<?..." with something that doesn't conflict with anything,
>>>>> perhaps starting in PHP 6?  No need to get out the torches and
>>>>>pitchforks,
>>>>> everyone!  As insane and problematic as that would be (i.e. BC break
>>>>>with
>>>>> roughly 1/3 of the internet lol), I felt as though the subject should
>>>>>at
>>>>> least be broached.  ;P
>>>
>>>
>>> No need. Just keep it as <?php. It's already been well established. We
>>> should ovoid overcomplicating it.
>>>
>>> Luke
>>>
>>>
>>
>>
>>
>>--
>>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
Sorry, only registered users may post in this forum.

Click here to login