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

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

Ángel González — Tue, 10 Apr 2012 22:50:02 +0200

On 10/04/12 19:22, Chris Stockton wrote:
> Hello,
> I understand your point that you are trying to make, but forward
> compatibility I am not sure shares the same critical nature as
> backwards.
Sure, but if we can help with that when designing the feature, that's
much better, and I think would also ecourage into using it.

> I think a software provider who is aiming at supporting a
> wide variety of php versions is likely going to code around the lowest
> common denominator.
If they can easily work around it, it's much easier they start using it soon
than waiting for when common web hostings stop providing 5.4.

> Even still, if they chose to they could have two
> bootstrap files, one that included files with the new features and one
> with the old.
Of course, they still could, but is more troublesome. Specially if as you
suggest, they need to keep two files in sync. In that case it's probably
easier
to keep without the new features.

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

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

Chris Stockton — Tue, 10 Apr 2012 19:30:02 +0200

Hello,

2012/4/10 Ángel González :
> Luke Scott wrote:
>>> 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
> I had assumed require_code would work with brackets around the parameters..
> Someone mentioned it, but you raise a good point in that it's not stated
> by the
> rfc, and would need to be explicitely supported.
>
> There are people calling require and friends with brackets, but that
> likely (ie.
> not looking at the lexer) works because the parameter is ('foo') which
> resolves
> as 'foo'. That wouldn't work when there are two of them.
> I think it should be something to consider when making the patch, though.
>
>

I understand your point that you are trying to make, but forward
compatibility I am not sure shares the same critical nature as
backwards. I think a software provider who is aiming at supporting a
wide variety of php versions is likely going to code around the lowest
common denominator. Even still, if they chose to they could have two
bootstrap files, one that included files with the new features and one
with the old.

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

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

Ángel González — Tue, 10 Apr 2012 18:00:02 +0200

Hello Chris,

Chris Stockton wrote:
> I am not sure I am following you here Angel, are you confusing
> backwards and forward compatibility?
It can probably be termed both ways, depending on which version you stay.
I'm refering to the ability of a php file to work in both version 5.4
and 5.5 yet
take advantage of a 5.5 feature if available.

> 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 introduction of a new function is a good example of compatibility. The
code can easily detect and fall back

function getRandomNumber() {
if (function_exists('rand'))
return rand();
else
return 4; // chosen by fair dice roll, guaranteed to be random
}

or even show a graceful error message (instead of a cryptic php error):

if ( version_compare(PHP_VERSION, '5.4', '<') )
die("This program requires the awesome 5.4 version of PHP");

class Foo {
use Bar;
...
}

The later one is an example of what would *not* work, since even though
the developer tried to show a clear error to the end user unexpectedly
installing in an older php version than supported, he would get
"PHP Parse error: syntax error, unexpected T_USE, expecting T_FUNCTION"
which in no way leads them to the "You need to update PHP" conclusion.

> 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.
The goal is to allow use of the new characteristics without having to drop
support for old PHP versions, which is something typically done quite
conservately.
In this case, it would even be possible to make a userland include_code on
old versions by falling back to an eval(). Not as good, but the codebase
is still
supporting the old PHP engines (back to X version).

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

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

Ángel González — Tue, 10 Apr 2012 18:00:02 +0200

Luke Scott wrote:
>> 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
I had assumed require_code would work with brackets around the parameters.
Someone mentioned it, but you raise a good point in that it's not stated
by the
rfc, and would need to be explicitely supported.

There are people calling require and friends with brackets, but that
likely (ie.
not looking at the lexer) works because the parameter is ('foo') which
resolves
as 'foo'. That wouldn't work when there are two of them.
I think it should be something to consider when making the patch, though.

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

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

Tom Boutell — Tue, 10 Apr 2012 17:10:02 +0200

Yes, those points (keep the same keywords, optional second parameter,
OR'd constants) have been made a few times, and I plan to edit the RFC
accordingly.

On Tue, Apr 10, 2012 at 10:53 AM, Luke Scott wrote:
> Tom,
>
> On Apr 10, 2012, at 6:48 AM, Tom Boutell wrote:
>
>> The "second part" in the RFC is just a suggested filename convention,
>> it is not a hardcoded requirement. I'm not sure that's what you're
>> talking about here.
>>
>> The RFC I'm referring to does not propose completely removing the
>> availability of the >>
>> https://wiki.php.net/rfc/source_files_without_opening_tag
>
> I would prefer to use the existing
> require/include/include_once/require_once keywords. Just add a second
> optional parameter to each.
>
> Also since these keywords are constructs it would be better to used
> or'd constants rather than an array.
>
> Luke
>
>>
>> On Tue, Apr 10, 2012 at 8:55 AM, Rafael Kassner wrote:
>>> IMHO, both parts can be separated. My personal opinion: the require_path
>>> with the php mode only can be useful, a mime type or extension for these
>>> files too, but I'm not sure about removing " >>> first part can be approved sooner than the second, or maybe the entire RFC
>>> would not be approved because the second.
>>>
>>> On Tue, Apr 10, 2012 at 9:35 AM, Tom Boutell wrote:
>>>>
>>>> An important clarification: the RFC has two parts, NOT two options.
>>>> Yasuo Ohgaki made many edits to the RFC before deciding to create his
>>>> own RFC. He backed out most of his edits but somewhere along the line
>>>> he introduced the words "Option 1" and "Option 2" for two things that
>>>> are meant to go tegether. The intention is to have both the new
>>>> functionality (the require_path keyword, or whatever that evolves
>>>> into) AND a strongly encouraged naming convention for PHP files of the
>>>> two types (see my original draft).
>>>>
>>>> I have corrected the RFC to read as intended.
>>>>
>>>> I'll be updating it with a second version shortly but wanted to clear
>>>> up this confusion first.
>>>>
>>>> (I think it would be best for RFCs to have a single author of group of
>>>> authors who are in agreement about the intent of the RFC. Proposing an
>>>> alternative RFC, as Yasuo Ohgaki is now doing, is a much less
>>>> confusing way to put forward a concept the original author does not
>>>> agree with.)
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Atenciosamente,
>>> Rafael Kassner
>>>
>>
>>
>>
>> --
>> 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

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

Luke Scott — Tue, 10 Apr 2012 17:00:11 +0200

Tom,

On Apr 10, 2012, at 6:48 AM, Tom Boutell wrote:

> The "second part" in the RFC is just a suggested filename convention,
> it is not a hardcoded requirement. I'm not sure that's what you're
> talking about here.
>
> The RFC I'm referring to does not propose completely removing the
> availability of the >
> https://wiki.php.net/rfc/source_files_without_opening_tag

I would prefer to use the existing
require/include/include_once/require_once keywords. Just add a second
optional parameter to each.

Also since these keywords are constructs it would be better to used
or'd constants rather than an array.

Luke

>
> On Tue, Apr 10, 2012 at 8:55 AM, Rafael Kassner wrote:
>> IMHO, both parts can be separated. My personal opinion: the require_path
>> with the php mode only can be useful, a mime type or extension for these
>> files too, but I'm not sure about removing " >> first part can be approved sooner than the second, or maybe the entire RFC
>> would not be approved because the second.
>>
>> On Tue, Apr 10, 2012 at 9:35 AM, Tom Boutell wrote:
>>>
>>> An important clarification: the RFC has two parts, NOT two options.
>>> Yasuo Ohgaki made many edits to the RFC before deciding to create his
>>> own RFC. He backed out most of his edits but somewhere along the line
>>> he introduced the words "Option 1" and "Option 2" for two things that
>>> are meant to go tegether. The intention is to have both the new
>>> functionality (the require_path keyword, or whatever that evolves
>>> into) AND a strongly encouraged naming convention for PHP files of the
>>> two types (see my original draft).
>>>
>>> I have corrected the RFC to read as intended.
>>>
>>> I'll be updating it with a second version shortly but wanted to clear
>>> up this confusion first.
>>>
>>> (I think it would be best for RFCs to have a single author of group of
>>> authors who are in agreement about the intent of the RFC. Proposing an
>>> alternative RFC, as Yasuo Ohgaki is now doing, is a much less
>>> confusing way to put forward a concept the original author does not
>>> agree with.)
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> Atenciosamente,
>> Rafael Kassner
>>
>
>
>
> --
> 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

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

Tom Boutell — Tue, 10 Apr 2012 15:50:02 +0200

The "second part" in the RFC is just a suggested filename convention,
it is not a hardcoded requirement. I'm not sure that's what you're
talking about here.

The RFC I'm referring to does not propose completely removing the
availability of the
https://wiki.php.net/rfc/source_files_without_opening_tag

On Tue, Apr 10, 2012 at 8:55 AM, Rafael Kassner wrote:
> IMHO, both parts can be separated. My personal opinion: the require_path
> with the php mode only can be useful, a mime type or extension for these
> files too, but I'm not sure about removing " > first part can be approved sooner than the second, or maybe the entire RFC
> would not be approved because the second.
>
> On Tue, Apr 10, 2012 at 9:35 AM, Tom Boutell wrote:
>>
>> An important clarification: the RFC has two parts, NOT two options.
>> Yasuo Ohgaki made many edits to the RFC before deciding to create his
>> own RFC. He backed out most of his edits but somewhere along the line
>> he introduced the words "Option 1" and "Option 2" for two things that
>> are meant to go tegether. The intention is to have both the new
>> functionality (the require_path keyword, or whatever that evolves
>> into) AND a strongly encouraged naming convention for PHP files of the
>> two types (see my original draft).
>>
>> I have corrected the RFC to read as intended.
>>
>> I'll be updating it with a second version shortly but wanted to clear
>> up this confusion first.
>>
>> (I think it would be best for RFCs to have a single author of group of
>> authors who are in agreement about the intent of the RFC. Proposing an
>> alternative RFC, as Yasuo Ohgaki is now doing, is a much less
>> confusing way to put forward a concept the original author does not
>> agree with.)
>>
>> --
>> 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
>>
>
>
>
> --
> Atenciosamente,
> Rafael Kassner
>

--
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

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

Rafael Kassner — Tue, 10 Apr 2012 15:00:11 +0200

IMHO, both parts can be separated. My personal opinion: the require_path
with the php mode only can be useful, a mime type or extension for these
files too, but I'm not sure about removing " first part can be approved sooner than the second, or maybe the entire RFC
would not be approved because the second.

On Tue, Apr 10, 2012 at 9:35 AM, Tom Boutell wrote:

> An important clarification: the RFC has two parts, NOT two options.
> Yasuo Ohgaki made many edits to the RFC before deciding to create his
> own RFC. He backed out most of his edits but somewhere along the line
> he introduced the words "Option 1" and "Option 2" for two things that
> are meant to go tegether. The intention is to have both the new
> functionality (the require_path keyword, or whatever that evolves
> into) AND a strongly encouraged naming convention for PHP files of the
> two types (see my original draft).
>
> I have corrected the RFC to read as intended.
>
> I'll be updating it with a second version shortly but wanted to clear
> up this confusion first.
>
> (I think it would be best for RFCs to have a single author of group of
> authors who are in agreement about the intent of the RFC. Proposing an
> alternative RFC, as Yasuo Ohgaki is now doing, is a much less
> confusing way to put forward a concept the original author does not
> agree with.)
>
> --
> 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
>
>

--
Atenciosamente,
Rafael Kassner

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

Tom Boutell — Tue, 10 Apr 2012 14:40:02 +0200

An important clarification: the RFC has two parts, NOT two options.
Yasuo Ohgaki made many edits to the RFC before deciding to create his
own RFC. He backed out most of his edits but somewhere along the line
he introduced the words "Option 1" and "Option 2" for two things that
are meant to go tegether. The intention is to have both the new
functionality (the require_path keyword, or whatever that evolves
into) AND a strongly encouraged naming convention for PHP files of the
two types (see my original draft).

I have corrected the RFC to read as intended.

I'll be updating it with a second version shortly but wanted to clear
up this confusion first.

(I think it would be best for RFCs to have a single author of group of
authors who are in agreement about the intent of the RFC. Proposing an
alternative RFC, as Yasuo Ohgaki is now doing, is a much less
confusing way to put forward a concept the original author does not
agree with.)

--
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

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

Ferenc Kovacs — Tue, 10 Apr 2012 11:50:02 +0200

On Tue, Apr 10, 2012 at 10:54 AM, Yasuo Ohgaki wrote:

> Hi,
>
> First of all, the proposal is threat mitigation and not for a
> complete countermeasure for LFI.
>

yep, and I think that there is no transparent solution which would make
impossible to havi LFI vulnerability without seriously crippling the
language.

>
> 2012/4/10 Ferenc Kovacs :
> >>
> >> "allow_url_include" and "template_mode" is similar to me.
> >>
> >> allow_url_include: enable only when url include is needed.
> >> template_mode: enable only when template mode is needed.
> >>
> >> allow_url_include prevents RFI which may result in critical security
> >> incident.
> >> template_mode prevents LFI which may result in critical security
> incident.
> >>
> >> Note: template_mode=off is script only mode. On is current behavior.
> >>
> >
> > I just glanced over the RFC.
> > See my comments below:
> > "LFI/RFI is fatal security error. Currently, LFI prevention is upto
> > programmers and framework authors/system admins do not have feasible way
> to
> > prevent LFI"
> > what about open_basedir?
>
> It's mitigation feature like template_mode=off.
>

I think it should be mentioned, because now it sounds from the RFC that
there is nothing available in this regard.

>
> >
> > "Current PHP is weak to script injections compare to other languages
> such as
> > Ruby/Perl/Phthon/Lua/etc."
> > would be nice listing what does those languages do better in thise
> regard.
> > AFAIK ruby allows you to include arbitrary files, and the rails security
> > guides even mention the file upload
> > vulnerability:
> http://guides.rubyonrails.org/security.html#executable-code-in-file-uploads
> > perl also have require, Python has import, which is maybe a little bit
> > harder to misuse, lua has both dofile and require.
> > it would be nice explaining what do you mean by php being week compared
> to
> > those languages.
>
> I know these language/framework may have similar vulnerability even Java
> had.
> What I would like to point out it "LFI in PHP is *very* easy with
> respect to other
> languages due to embedded language nature".
>
> We can tell it from number of CVEs for LFIs.
> That's the reason why there would be better to have additional protection..
>

maybe. but it can be accounted for other factors (like the popularity of
the language, or the difference in the skill/knowledge of the average php
developer/application vs the other languages).
so I think it would be nice to explain what are those technical advantages
the other languages have over php, instead of jumping to conclusion based
on the number of the CVE numbers.

> > I think that it would be really hard to adopt. Framework developers are
> > trying to support the widest audience, and supporting both template_mode
> On
> > and Off will be a major PITA imo.
>
> As I wrote in RFC example, supporting both is simple.
>
> 1. Disable template_mode=off in bootstrap, if they would like to enjoy
> mitigation.
> 2. Enable template_mode before render.
> 3. Disable template_mode after render.
>

ok, so this would be an PHP_INI_ALL setting.
of course if you would like to use this feature to prevent the injection of
php code to the data files(and the execution), you should still have to
disable the php_engine on the upload directory (or enable template_mode for
that dir at least)
so we can say that for public accessible/executable user uploads, this
feature can't do much.

>
> > I think it would require far less work to find and fix the LFIs and
> properly
> > configure the webserver than rewriting your whole application (including
> > your libraries).
> >
> > IDEs would be in the same spot, they can't tell you that whether or not
> your
> > file is missing the opening tags without looking into your php.ini/apache
> > vhost/.htaccess config.
> > it can be either fine or a bug, depending on the value of template_mode
>
> I think you have missed RFC spec.
> Even when template_mode=off, " > allowed for compatibility.
>

yeah, I only noticed this later on, and didn't bothered to correct here.

>
> > as Stas pointed out, if you migrate your codebase which depends on
> > template_mode = Off, and you forgot to change the default php.ini (yeah,
> you
> > should notice this before going live, but we are talking about the people
> > having LFI and other vulns...) then your files will be served by your
> > webserver as is. which itself can compromise your system.
>
> I think this could be verified easily by find and grep or IDE search.
> Modern script would not have needless PHP files under docroot also.
>

yeah, but it is still a problem, that your IDE will be a hard time to
properly catch.
currently the tags are always available, if your RFC get's
accepted, this can be turned off by runtime.

>
> > "With this RFC, the only allowed PHP tag under non embed mode is
> ” >
> No. >

yeah, this was another inconsistency in the RFC.

> Anyone wants