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

Hi,

2012/4/10 Chris Stockton <[email protected]>:
>> People does this should not security issues, though.

I should have written

People does this should know security issues, though.

then you might make sense with it.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

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

Hi,

2012/4/10 Luke Scott <[email protected]>:
> On Apr 9, 2012, at 9:08 PM, Yasuo Ohgaki <[email protected]> wrote:
>
>>> I would actually suggest that require/include stop supporting remote
>>> files all together. But that can be a different RFC.
>>>
>>> This "security problem" isn't a problem with common sense.
>>
>> Requiring/Including remote file is not bad, just like embedded mode
>> of PHP is not bad.
>
> You can fetch a remote file with curl, socket functions, he'll even
> file_get_contents. Point is you shouldn't be using require/include for
> including remote files. It's not the purpose of these functions, and
> even though "you can" it doesn't mean you should and it's highly
> discouraged.

I strongly discourage setting allow_url_include=on, too.
Enabling it only when it is needed is okay.

I think you are concerned about security, so you could agree to have
option for disabling embedded mode by option, couldn't you?

>
> It's not a core PHP problem. It's programming problem.
>
> Where I work we forbid certain things like this for good reason. We
> also have a code review process. All code is checked by another
> developer before it gets commited. Even my code, and I'm a manager.
> This should be done at the very least. Some companies do this and then
> have a third party audit the code on top of it.

Letting programmers decide what to do is good as well as giving secure
default and secure standards.

PHP is programming language anyway.

Programming languages should give freedom to write suicide code
more or less. Otherwise, it will limit creative work of programmers.
Not limiting or prohibiting some feature, "Setting reasonable default
behavior" is what PHP project should do. IMO.

>> They are bad for security if they are enabled by default or mandatory.
>
> Again nothing has changed with this RFC.

That's the problem.
If PHP is going to drop mandatory embedding, PHP should better to
remove LFI mess due to mandatory embed mode. IMHO

Mandatory embedded mode is insecure than optional one.
If other scripting languages have mandatory embed mode, then it may
stay as it is now. However, PHP is the only one that is too weak to LFI.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

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

On Apr 9, 2012, at 10:03 PM, Yasuo Ohgaki <[email protected]> wrote:

> I strongly discourage settingallow_url_include=on, too.

Good.

> Enabling it only when it is needed is okay.

No it's not. There is no reason to do so other than backwards
compatibility for very old code.

> I think you are concerned about security,

Absolutely.

> so you could agree to have
> option for disabling embedded mode by option, couldn't you?

Sure it can be an option. But it can't be the default, at least right
away. It's unreasonable. I would prefer an environmental variable to
choose the mode though. I'm not opposed to a php.ini option, but some
people are

(If by embedded mode you mean template mode, and non-embedded mode as
"pure code mode").

I still fail to see what this has to do with allow_url_include.

> Letting programmers decide what to do

Not in all cases.

> Programming languages should give freedom to write suicide code
> more or less.

No, it shouldn't.

All that you've said comes down to this:

Don't write bad code. Configure your web server properly.

The RFC isn't meant to address these issues, and quite frankly it
isn't a core PHP issue. It's no different than any language with an
eval() statement.

Keep in mind an RFC isn't gospel. And it's still being drafted. We
need to give Tom a chance to finish it.

Luke

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

On Mon, Apr 9, 2012 at 10:35 PM, Luke Scott <[email protected]> wrote:

> On Apr 9, 2012, at 10:03 PM, Yasuo Ohgaki <[email protected]> wrote:
>
> > I strongly discourage settingallow_url_include=on, too.
>
> Good.
>
> > Enabling it only when it is needed is okay.
>
> No it's not. There is no reason to do so other than backwards
> compatibility for very old code.
>
> > I think you are concerned about security,
>
> Absolutely.
>
> > so you could agree to have
> > option for disabling embedded mode by option, couldn't you?
>
> Sure it can be an option. But it can't be the default, at least right
> away. It's unreasonable. I would prefer an environmental variable to
> choose the mode though. I'm not opposed to a php.ini option, but some
> people are
>
> (If by embedded mode you mean template mode, and non-embedded mode as
> "pure code mode").
>
> I still fail to see what this has to do with allow_url_include.
>
> > Letting programmers decide what to do
>
> Not in all cases.
>
> > Programming languages should give freedom to write suicide code
> > more or less.
>
> No, it shouldn't.
>
> All that you've said comes down to this:
>
> Don't write bad code. Configure your web server properly.
>
> The RFC isn't meant to address these issues, and quite frankly it
> isn't a core PHP issue. It's no different than any language with an
> eval() statement.
>
> Keep in mind an RFC isn't gospel. And it's still being drafted. We
> need to give Tom a chance to finish it.
>
> Luke
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I feel obliged to point out that both sides of this argument have been
represented eloquently and fully IMHO. It now seems to have reached the
point where all substantive arguments have been said and thus are now
merely being repeated. The last few messages back-and-forth could, at
least one some level, be summarized simply as, "Yes it is!" and "No it
isn't!"

There's clearly a fundamental disagreement exposed here as to the role a
programming language should play pertaining to the prevention of vulnerable
code and whether the burden lies with the language or the programmer to
assume responsibility for this. My guess would be that it falls somewhere
in the middle, though I really haven't given it much thought to be honest.

I'd like to suggest that a new thread be created for this debate, since it
does seem to be sufficiently divergent from the original topic posted by
Tom. I would also be interested to hear why you believe it should or
should not be the role of the language to prevent exploitable code and to
what degree. Both sides have stated quite authoritatively that it is one
or the other, but what I'd like to see are some more in-depth arguments to
back-up those assertions. From a strictly academic standpoint, I think
this argument poses an interesting opportunity to explore this
philosophical divide in detail.


But regardless, let's at least move it to a separate topic so Tom can argue
the case for his RFC without too much distraction. =)

--Kris

Hi,

2012/4/10 Luke Scott <[email protected]>:
> On Apr 9, 2012, at 10:03 PM, Yasuo Ohgaki <[email protected]> wrote:
>
>> I strongly discourage settingallow_url_include=on, too.
>
> Good.
>
>> Enabling it only when it is needed is okay.
>
> No it's not. There is no reason to do so other than backwards
> compatibility for very old code.
>
>> I think you are concerned about security,
>
> Absolutely.
>
>> so you could agree to have
>> option for disabling embedded mode by option,  couldn't you?
>
> Sure it can be an option. But it can't be the default, at least right
> away. It's unreasonable. I would prefer an environmental variable to
> choose the mode though. I'm not opposed to a php.ini option, but some
> people are
>
> (If by embedded mode you mean template mode, and non-embedded mode as
> "pure code mode").
>
> I still fail to see what this has to do with allow_url_include.

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

>
>> Letting programmers decide what  to do
>
> Not in all cases.
>
>> Programming languages should give freedom to write suicide code
>> more or less.
>
> No, it shouldn't.
>
> All that you've said comes down to this:
>
> Don't write bad code. Configure your web server properly.

Wouldn't it be the same for allow_url_include?
One could argue the same way for it.

> The RFC isn't meant to address these issues, and quite frankly it
> isn't a core PHP issue. It's no different than any language with an
> eval() statement.

I suppose you have missed SQL injection and LFI vulnerability
discussion. LFI's true risk is misunderstood by many people,
just like session adoption risk. (which I'm willing to fix it also)

Note that SQL injection and LFI are common vulnerability
for PHP applications.

Please read the RFC how SQL injection is related to LFI.

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

template_mode is much like allow_url_include.
If user follow guideline, it eliminates LFI risk, just like RFI.

>
> Keep in mind an RFC isn't gospel. And it's still being drafted. We
> need to give Tom a chance to finish it.

I'm the one listed it under discussion :)

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

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

Hi,

2012/4/10 Kris Craig <[email protected]>:
>
>
> On Mon, Apr 9, 2012 at 10:35 PM, Luke Scott <[email protected]> wrote:
>>
>> On Apr 9, 2012, at 10:03 PM, Yasuo Ohgaki <[email protected]> wrote:
>>
>> > I strongly discourage settingallow_url_include=on, too.
>>
>> Good.
>>
>> > Enabling it only when it is needed is okay.
>>
>> No it's not. There is no reason to do so other than backwards
>> compatibility for very old code.
>>
>> > I think you are concerned about security,
>>
>> Absolutely.
>>
>> > so you could agree to have
>> > option for disabling embedded mode by option,  couldn't you?
>>
>> Sure it can be an option. But it can't be the default, at least right
>> away. It's unreasonable. I would prefer an environmental variable to
>> choose the mode though. I'm not opposed to a php.ini option, but some
>> people are
>>
>> (If by embedded mode you mean template mode, and non-embedded mode as
>> "pure code mode").
>>
>> I still fail to see what this has to do with allow_url_include.
>>
>> > Letting programmers decide what  to do
>>
>> Not in all cases.
>>
>> > Programming languages should give freedom to write suicide code
>> > more or less.
>>
>> No, it shouldn't.
>>
>> All that you've said comes down to this:
>>
>> Don't write bad code. Configure your web server properly.
>>
>> The RFC isn't meant to address these issues, and quite frankly it
>> isn't a core PHP issue. It's no different than any language with an
>> eval() statement.
>>
>> Keep in mind an RFC isn't gospel. And it's still being drafted. We
>> need to give Tom a chance to finish it.
>>
>> Luke
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
> I feel obliged to point out that both sides of this argument have been
> represented eloquently and fully IMHO.  It now seems to have reached the
> point where all substantive arguments have been said and thus are now merely
> being repeated.  The last few messages back-and-forth could, at least one
> some level, be summarized simply as, "Yes it is!" and "No it isn't!"
>
> There's clearly a fundamental disagreement exposed here as to the role a
> programming language should play pertaining to the prevention of vulnerable
> code and whether the burden lies with the language or the programmer to
> assume responsibility for this.  My guess would be that it falls somewhere
> in the middle, though I really haven't given it much thought to be honest..

I believe there is misunderstanding.
allow_url_include and templat_mode is very similar to me, yet
there is not an agreement.

>
> I'd like to suggest that a new thread be created for this debate, since it
> does seem to be sufficiently divergent from the original topic posted by
> Tom.  I would also be interested to hear why you believe it should or should
> not be the role of the language to prevent exploitable code and to what
> degree.  Both sides have stated quite authoritatively that it is one or the
> other, but what I'd like to see are some more in-depth arguments to back-up
> those assertions.  From a strictly academic standpoint, I think this
> argument poses an interesting opportunity to explore this philosophical
> divide in detail.
>
>
> But regardless, let's at least move it to a separate topic so Tom can argue
> the case for his RFC without too much distraction.  =)

These RFC is similar, but it's different.
That why I separated the RFC.

Why shouldn't thread. I'll post new one.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

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

On 10 April 2012 15:30, Yasuo Ohgaki <[email protected]> wrote:
> "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.

Honestly, I'd consider allow_url_include a mistake, and would hate to
see additional configuration dependent behaviour enter PHP, as I've
said before.

Adam

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

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

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

"PHP script inclusion detection may be done for data files. However, it's
not a simple task."
as I mentioned before, I don't think that it is the good way to try to
detect the injected code in the data files:
one should know beforehand that whether is the uploaded file is meant to be
a data file or a script file, and act accordingly.

"Almost all applications are not checking these and it would be impossible
to make developers do a proper validation."
these kind of filtering techniques are error prone.

"Disabling embed(template) mode is simple solution for this issue."
one can still upload valid embed files and if the LFI is present, execute
those.

so your solution would only improve this problem, if an LFI vulnerability
is present or the uploaded files are publically accessible and not excluded
from the execution and the file uploads otherwise properly type validated
and the developer choses to be compatible with the template_mode off and
disables it(as the default would be on).
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.
and until they do, the average developer can't be expected to make his
choice of framework compatible with template_mode off, so he/she won't use
it.
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

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.

"With this RFC, the only allowed PHP tag under non embed mode is ”<?php”."
oh, isn't that contradicting "This RFC proposes removal of PHP tags (<?php
and so forth) from the PHP script by php.ini or CLI option flags." and "Not
a few programmers may once have been bothered to put a PHP tag at the top
of every PHP script that only contains classes and functions. In short, PHP
tags are just ancient."
although it would lessen the BC/incompatibility problems mentioned above.

In general I'm -1 on this RFC, I think that the people who are vulnerable
wouldn't use it, and there are better alternatives for the described
problems than the introduction of template_mode.
this would add an additional level of complexity and would make it harder
to write portable code.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Hi,

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

2012/4/10 Ferenc Kovacs <[email protected]>:
>>
>> "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.

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

> "PHP script inclusion detection may be done for data files. However, it's
> not a simple task."
> as I mentioned before, I don't think that it is the good way to try to
> detect the injected code in the data files:
> one should know beforehand that whether is the uploaded file is meant to be
> a data file or a script file, and act accordingly.
>
> "Almost all applications are not checking these and it would be impossible
> to make developers do a proper validation."
> these kind of filtering techniques are error prone.

Agreed.

>
> "Disabling embed(template) mode is simple solution for this issue."
> one can still upload valid embed files and if the LFI is present, execute
> those.
>
> so your solution would only improve this problem, if an LFI vulnerability is
> present or the uploaded files are publically accessible and not excluded
> from the execution and the file uploads otherwise properly type validated
> and the developer choses to be compatible with the template_mode off and
> disables it(as the default would be on).

Yes, it should be considered as mitigation. However, it is good one.

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

For good frameworks, it will be a few lines of changes.

> and until they do, the average developer can't be expected to make his
> choice of framework compatible with template_mode off, so he/she won't use
> it.

It would be easy enough for framework users to adopt template_mode.
So they can make changes to framework. Perhaps, they could contribute
it.

> 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, "<?php" at the beginning of script file is
allowed for compatibility.

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

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

No. <?php <? <% and others are allowed.

Anyone wants <script language="php">?

> oh, isn't that contradicting "This RFC proposes removal of PHP tags (<?php
> and so forth) from the PHP script by php.ini or CLI option flags." and "Not
> a few programmers may once have been bothered to put a PHP tag at the top of
> every PHP script that only contains classes and functions. In short, PHP
> tags are just ancient."
> although it would lessen the BC/incompatibility problems mentioned above.

Thanks for catching it.
It was written for April Fool day by Moriyoshi.
I should have edited his joke :)

>
> In general I'm -1 on this RFC, I think that the people who are vulnerable
> wouldn't use it, and there are better alternatives for the described
> problems than the introduction of template_mode.

Are there? I should have missed.
What is the better alternative?

> this would add an additional level of complexity and would make it harder to
> write portable code.

This is misunderstanding.
You might be felt by the part of April Fool's joke.
I'll edit the part from now and please reconsider.

Regards,

--
Yasuo Ohgaki

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

On Tue, Apr 10, 2012 at 10:54 AM, Yasuo Ohgaki <[email protected]> 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 <[email protected]>:
> >>
> >> "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, "<?php" at the beginning of script file is
> 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 <?php ?> 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
> ”<?php”."
>
> No. <?php <? <% and others are allowed.
>

yeah, this was another inconsistency in the RFC.


> Anyone wants <script language="php">?
>

personally I don't. at all.


>
> > oh, isn't that contradicting "This RFC proposes removal of PHP tags
> (<?php
> > and so forth) from the PHP script by php.ini or CLI option flags." and
> "Not
> > a few programmers may once have been bothered to put a PHP tag at the
> top of
> > every PHP script that only contains classes and functions. In short, PHP
> > tags are just ancient."
> > although it would lessen the BC/incompatibility problems mentioned above.
>
> Thanks for catching it.
> It was written for April Fool day by Moriyoshi.
> I should have edited his joke :)
>

I think it would be better to leave as is, and create a separate RFC from
the scratch, so that we don't have issues like this.


>
> >
> > In general I'm -1 on this RFC, I think that the people who are vulnerable
> > wouldn't use it, and there are better alternatives for the described
> > problems than the introduction of template_mode.
>
> Are there? I should have missed.
> What is the better alternative?
>

personally I wouldn't need a solution which could in some but not all cases
save me from my security bugs.
this would be abused like safe_mode and magic_quotes was.
false sense of security, which would make people lazy about fixing the real
problem (LFI/RFI, executable file uploads, etc.)


>
> > this would add an additional level of complexity and would make it
> harder to
> > write portable code.
>
> This is misunderstanding.
> You might be felt by the part of April Fool's joke.
> I'll edit the part from now and please reconsider.
>

I will re-read it tomorrow.


--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

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

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 "<?php". Maybe splitting it, the
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 <[email protected]> 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

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 <?php tag. There are two RFCs active. Please see:

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

On Tue, Apr 10, 2012 at 8:55 AM, Rafael Kassner <kassner@gmai[email protected]> 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 "<?php". Maybe splitting it, the
> 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 <[email protected]> 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,

On Apr 10, 2012, at 6:48 AM, Tom Boutell <[email protected]> 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 <?php tag. There are two RFCs active. Please see:
>
> 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 <[email protected]> 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 "<?php". Maybe splitting it, the
>> 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 <[email protected]> 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

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 <[email protected]> wrote:
> Tom,
>
> On Apr 10, 2012, at 6:48 AM, Tom Boutell <[email protected]> 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 <?php tag. There are two RFCs active. Please see:
>>
>> 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 <[email protected]> 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 "<?php". Maybe splitting it, the
>>> 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 <[email protected]> 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

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

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

Hello,

2012/4/10 Ángel González <[email protected]>:
> 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

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