Hi Tom,
It's better to distinguish security related issue and others.
Therefore, I listed Moriyoshi's proposal to RFC list and put
my proposal in it. His proposal is almost the same as mine
except the flag for embed mode control.
https://wiki.php.net/rfc/nophptags
I recovered the original
.phpp would be fine.
.phpp code needs to be able to interoperate with .php templates, otherwise one
can't supply reusable libraries that implement generic algorithms without
surprises for those who integrate them in older projects.
Sent from my iPhone
On Apr 9, 2012, at 1:16 AM, Kris Craig
I think separating these rfcs makes sense, thanks.
Sent from my iPhone
On Apr 9, 2012, at 2:17 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Tom,
It's better to distinguish security related issue and others.
Therefore, I listed Moriyoshi's proposal to RFC list and put
my proposal in it.
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
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 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
On Apr 9, 2012, at 9:16 AM, Tom Boutell t...@punkave.com 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
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
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 t...@punkave.com wrote:
I see what you're saying, but
On Apr 9, 2012, at 10:23 AM, Tom Boutell t...@punkave.com 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
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
On Apr 9, 2012, at 10:44 AM, Ralph Schindler ra...@ralphschindler.com 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,
Hello,
On Mon, Apr 9, 2012 at 10:43 AM, Ralph Schindler
ra...@ralphschindler.com 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,
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
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
autoloaders (as is typical in almost any project that would be
interested in .phpc files in the first place) rather than repeatedly
I am partial to file.p btw.
PHP without the HP, or Hypertext Pre-Processing- whatever that is! ;)
In fact, it could mean PHP without the Html Passthrough. You get
On 09/04/12 19:36, Luke Scott wrote:
On Apr 9, 2012, at 10:23 AM, Tom Boutell t...@punkave.com 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.
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
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
Hi,
2012/4/10 Stas Malyshev smalys...@sugarcrm.com:
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
On Apr 9, 2012, at 12:27 PM, Ángel González keis...@gmail.com wrote:
On 09/04/12 19:36, Luke Scott wrote:
On Apr 9, 2012, at 10:23 AM, Tom Boutell t...@punkave.com wrote:
Also, your objection - that 'require_code' is confusing - would most
likely be an issue for a handful of people who write
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
On Apr 9, 2012, at 12:16 PM, Ángel González keis...@gmail.com 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
Hi,
2012/4/10 Stas Malyshev smalys...@sugarcrm.com:
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
Tom,
On Apr 9, 2012, at 11:26 AM, Tom Boutell t...@punkave.com 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
Hi,
2012/4/10 Stas Malyshev smalys...@sugarcrm.com:
Hi!
I'm not sure I follow - which PHP vulnerability you are talking about?
Local file includes. (LFI)
I'm not sure I understand - where's the vulnerability?
There is a null byte protection for LFI and I really like to the protection.
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)
Tom,
On Mon, Apr 9, 2012 at 1:20 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi,
2012/4/10 Stas Malyshev smalys...@sugarcrm.com:
Hi!
I'm not sure I follow - which PHP vulnerability you are talking about?
Local file includes. (LFI)
I'm not sure I understand - where's the
Hello,
2012/4/9 Ángel González keis...@gmail.com:
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
Hi,
I forgot to answer a question.
2012/4/10 Yasuo Ohgaki yohg...@ohgaki.net:
Hi,
2012/4/10 Stas Malyshev smalys...@sugarcrm.com:
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
It's easy to say write correct code. don't write stupid code, but
we cannot enforce it in real world.
I'm concerning both arbitrarily script execution and arbitrarily
information disclosure. Good example is LFI and SQL injection
attack.
Uh yeah there is. I won't employ someone who insists
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
As far as I know, you've already met that req by posting the RFC here, so
go ahead and add it. In the future, remember there's also an In Draft
status for RFCs that haven't been announced here yet. :)
On Apr 8, 2012 9:32 AM, Tom Boutell t...@punkave.com wrote:
I have written an RFC proposing
I don't think I have the privilege of editing the main page that lists
all the RFCs.
The template should probably say In Draft rather than starting out
with the wrong status (:
On Sun, Apr 8, 2012 at 5:10 PM, Kris Craig kris.cr...@gmail.com wrote:
As far as I know, you've already met that req
Hi,
Moriyoshi has created same entry on 4/1, but
it seems it was deleted already.
Anyway, he had a patch for it.
https://gist.github.com/2266652
As I mentioned in other thread, we should better to have
a switch to disable embed mode for security reasons.
Regards,
--
Yasuo Ohgaki
Hi,
There is RFC that is written by Moriyoshi.
It's not listed in RFC page, though.
https://wiki.php.net/rfc/nophptags
I think these should be merged.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
2012/4/9 Yasuo Ohgaki yohg...@ohgaki.net:
Hi,
Moriyoshi has created same entry on 4/1, but
Moriyoshi was kidding, as near as I can tell (:
To take it at face value though, the *cough* April 1st *cough*
proposal of Moriyoshi calls for the complete abolition of the feature
with no backwards compatibility with existing code that uses PHP as a
template language... including most popular
Hi,
I talked on twitter.
Yes, he is kidding, but he is serious, too.
I've added the RFC to Under Discussion and added
security issue description. I also added my proposal that
controls embed mode.
BTW, I don't think we need new require_path why don't
we use
require file.php, ture;
or some
Thanks. However, would you please fix the summary on the RFC's page to
match the summary in the actual RFC? As you have written it, it
implies that support for ?php would be completely removed. This is
not the case.
As for adding a boolean parameter to the require keyword, as the RFC
mentions
Tom,
On Sun, Apr 8, 2012 at 4:14 PM, Tom Boutell t...@punkave.com wrote:
Thanks. However, would you please fix the summary on the RFC's page to
match the summary in the actual RFC? As you have written it, it
implies that support for ?php would be completely removed. This is
not the case.
Hi,
I modified the title.
* include vs. require behavior (warning vs. error on failure)
* once vs. every time (require_once vs. require)
And we are proposing a third:
Then, better name would be require_script()/include_script().
However, this option will not solve script inclusion security
40 matches
Mail list logo
