Re: [PHP-DEV] Threading issues with internal classes
Hi, 2012/4/6 Johannes Schlüter johan...@schlueters.de: P.P.S. Would anybody mind if we drop TSRM/ZTS? :-) Ubuntu users and Apache 2.4 users may. It is working although I prefer non-ZTS. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] how do you create a private property as an array in a class
Thanks.
How can I valgrind my extension? Google isn't bringing up many php
extension topics :/
I can't figure out why I keep getting a seg fault:
typedef struct _foo_object {
zend_object std;
zval *elements;
} foo_object;
static foo_object *foo_object_ptr;
PHP_MINIT_FUNCTION(foo_class)
{
foo_object_ptr = emalloc(sizeof(foo_object));
MAKE_STD_ZVAL(foo_object_ptr-elements);
array_init(foo_object_ptr-elements);
return SUCCESS;
}
MAKE_STD_ZVAL(foo_object_ptr-elements);
array_init(foo_object_ptr-elements);
These two lines are causing the seg fault, I'm trying to understand why.
On Sat, Apr 7, 2012 at 8:41 PM, Xinchen Hui larue...@gmail.com wrote:
hi：
You can refer to ext spl array
Thanks
Sent from my iPhone
在 2012-4-8，7:12，Matthew Hernandez proxil...@gmail.com 写道：
Here's what I have so far:
typedef struct _foo_class_object {
zend_object std;
zval *elements;
int size;
} foo_class_object;
static foo_class_object *foo_class_object_ptr;
static zend_class_entry *foo_class_ptr;
ZEND_METHOD(foo_class, __construct) {
foo_class_object_ptr = (foo_class_object
*)zend_object_store_get_object(getThis() TSRMLS_CC);
array_init(foo_class_object_ptr-elements);
}
ZEND_METHOD(foo_class, add) {
zval *this = getThis();
zval *item;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, z, item) ==
FAILURE) {
RETURN_FALSE;
}
add_next_index_zval(foo_class_object_ptr-elements, item);
RETURN_TRUE;
}
However, this doesn't work. when you call FooClass::add it causes a
segfault. I'm sure I'm abusing something :)
thx
On Sat, Apr 7, 2012 at 2:38 PM, Matthew Hernandez proxil...@gmail.com
wrote:
Hi Johannes,
Yes I just found out that I should extend instead of the approach I was
thinking about.
So I created this:
typedef struct _foo_object {
zend_object std;
zval *array;
int size;
} foo_object;
So the question is how do I correctly pass foo_object around so that I
can
manipulate *array ? Having a private variable would mean calling
getThis()
and handling it that way would be trivial.
Are there any examples I could see? I'm using the slides from your
presentation in 2009 to help me.
thanks
On Sat, Apr 7, 2012 at 2:27 PM, Johannes Schlüter
johan...@schlueters.dewrote:
Hi,
On Sat, 2012-04-07 at 11:23 -0700, Matthew Hernandez wrote:
This is my first extension I'm working on. I'm trying to make a class
available to the user space with 1 private property that is an array.
The first question is: Why? - Why add the overhead of creating such an
array if it is private? In most cases it is better to extend the
zend_object in C (struct my_object { zend_object inner; type
some_data;}) to hold private data. If you want to show it in var_dump
or
a debugger you could implement a debug_info hook.
johannes
Re: [PHP-DEV] how do you create a private property as an array in a class
On Sat, 7 Apr 2012, Matthew Hernandez wrote:
How can I valgrind my extension? Google isn't bringing up many php
extension topics :/
On the shell:
export USE_ZEND_ALLOC=0
export ZEND_DONT_UNLOAD_MODULES=1
valgrind php -dextension=yourextension.so yourscript.php
See for some more info here:
http://derickrethans.nl/valgrinding-shared-modules.html
I can't figure out why I keep getting a seg fault:
typedef struct _foo_object {
zend_object std;
zval *elements;
} foo_object;
static foo_object *foo_object_ptr;
You really want to avoid real globals like this though, as it makes
things not thread-safe.
Also, please don't top-reply on this list.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without ?php at the top
2012/4/8, Yasuo Ohgaki:
2012/4/8 Ángel González keis...@gmail.com:
How does it help security?
If any, requiring '?php' before executable code makes easier to filter
out malicious files on apps with uploads in case there's a local
inclusion vulnerability somewhere.
Attackers may inject PHP script almost anything/anywhere since
PHP code may be embed anywhere in a file.
For example, malicious PHP script may be in GIF something like
gif89a ...any data.. ?php exec('rm -rf /') ?
and all attacker have to do is include/require the data somehow.
Attacker cannot do that this for other languages, since they are
not a embedded language. I know case that attackers may inject
malicious perl/ruby script in data files, but PHP is too easy
compare to these languages.
Regards,
--
Yasuo Ohgaki
Yes, but if I properly check that there's no '?php' in the uploaded files
(as you should verify everything you allow users to upload), it can't be
exploited.
OTOH if the vulnerable include is not an include but an include_code,
they could
use a file which was
exec(rm -rf); // Example of what not to do
And was happily uploaded as plain text.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without ?php at the top
This is an attempt to protect people who have written inherently insecure code
anyway. One should never do a dynamic require to any untrusted location, if
ever at all, yes?
Sent from my iPhone
On Apr 8, 2012, at 8:00 AM, Ángel González keis...@gmail.com wrote:
2012/4/8, Yasuo Ohgaki:
2012/4/8 Ángel González keis...@gmail.com:
How does it help security?
If any, requiring '?php' before executable code makes easier to filter
out malicious files on apps with uploads in case there's a local
inclusion vulnerability somewhere.
Attackers may inject PHP script almost anything/anywhere since
PHP code may be embed anywhere in a file.
For example, malicious PHP script may be in GIF something like
gif89a ...any data.. ?php exec('rm -rf /') ?
and all attacker have to do is include/require the data somehow.
Attacker cannot do that this for other languages, since they are
not a embedded language. I know case that attackers may inject
malicious perl/ruby script in data files, but PHP is too easy
compare to these languages.
Regards,
--
Yasuo Ohgaki
Yes, but if I properly check that there's no '?php' in the uploaded files
(as you should verify everything you allow users to upload), it can't be
exploited.
OTOH if the vulnerable include is not an include but an include_code,
they could
use a file which was
exec(rm -rf); // Example of what not to do
And was happily uploaded as plain text.
--
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
[PHP-DEV] Re: Addition of calendar to intl
On Sun, 08 Apr 2012 01:38:46 +0100, Stas Malyshev smalys...@sugarcrm.com wrote: http://icu-project.org/apiref/icu4c/classCalendar.html I hope the times of commit huge patches first, discuss them and document later if ever are behind us. Or at least we should try to put them behind us. I think the documentation part in this case is not as problematic, because the interface has been thoroughly documented in the ICU project. Most of your next questions can be answered by reading http://userguide.icu-project.org/datetime/calendar As for the API, I'm not sure I understand properly what it is supposed to do (one of the downsides of no RFC). Is it for date calculations? What kinds of calculations you could do? See http://userguide.icu-project.org/datetime/calendar#TOC-Usage What is IntlGregorianCalendar class - and why there is Gregorian one, but not others? Because the other type calendars, while existing and been implemented as separate C++ classes in ICU, are not part of the ICU public API. You are supposed to instantiate them through a factory method and use only the generic operations defined in Calendar. GregorianCalendar is the only public subclass. You can instantiate it directly and use specific methods -- get/setGregorianChange (to change the Julian/Gregorian cutoff date) and isLeapYear. If I wanted to work with Hebrew calendar, how would I do that? By specifying @calendar=hebrew in the locale (either in intl.default_locale or by passing it to the factory method IntlCalendar::createInstance()). What does it do that DateTime doesn't? Asides from supporting many more types of calendars, it has millisecond precision (for dates not too back into the past or future), field rolling, more control on behavior in DST transitions (since ICU 49) and some localization options (e.g. localized day of week). For the timezones - what is the difference between these timezones and the ones DatTime has - is there something additional that these provide? The main drive for creating a IntlTimeZone class was simply to encapsulate ICU TimeZone objects, which the Calendar classes work with. Therefore, the support is limited and only the base ICU class for timezones is exposed, except for the methods that allow changing the TimeZone. ICU allows you to build timezones with arbitrary rules, import/export RFC2445 VTIMEZONE and a lot more, none of which are available with my patch. Still, there is already some functionality that doesn't exist in DateTimeZone, like timezone id canonization, localization of time zone names on 8 different formats and easier searching for timezones according to country and region. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Creating an RFC: do I need to be blessed somehow?
Hi folks, I'm attempting to create an RFC on wiki.php.net but I don't get a create this page button. Is this the right place for me to start an RFC? 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
Re: [PHP-DEV] Creating an RFC: do I need to be blessed somehow?
hi, Please request an account, then we can give you the RFC karma :) Cheers, On Sun, Apr 8, 2012 at 4:22 PM, Tom Boutell t...@punkave.com wrote: Hi folks, I'm attempting to create an RFC on wiki.php.net but I don't get a create this page button. Is this the right place for me to start an RFC? 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 -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Creating an RFC: do I need to be blessed somehow?
He registered a wiki account already. 2012.04.08. 16:27, Pierre Joye pierre@gmail.com ezt írta: hi, Please request an account, then we can give you the RFC karma :) Cheers, On Sun, Apr 8, 2012 at 4:22 PM, Tom Boutell t...@punkave.com wrote: Hi folks, I'm attempting to create an RFC on wiki.php.net but I don't get a create this page button. Is this the right place for me to start an RFC? 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 -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Creating new remote branch: Fatal error.. but still seem to have worked
суббота, 7 апреля 2012 г. пользователь Hannes Magnusson писал: Hello I pushed a new branch (with no changes) just now, and got the following fatal error. The branch seems to have been pushed just fine though? vagrant@lucid32:~/src/phd$ git checkout -b PHD_1_1 Switched to a new branch 'PHD_1_1' vagrant@lucid32:~/src/phd$ git branch -a * PHD_1_1 master remotes/origin/GWYNNE_PLAYS_HERE remotes/origin/HEAD - origin/master remotes/origin/MAIN remotes/origin/PHD_0_2 remotes/origin/PHD_0_4 remotes/origin/PHD_ENTERPRISE remotes/origin/RESTRUCTURE remotes/origin/master remotes/origin/rsync vagrant@lucid32:~/src/phd$ git diff PHD_1_1..master vagrant@lucid32:~/src/phd$ git push origin PHD_1_1 Enter passphrase for key '/home/vagrant/.ssh/id_rsa': Total 0 (delta 0), reused 0 (delta 0) remote: Welcome bjori. remote: Changesets accepted. Thank you for your contribution. remote: remote: fatal: ambiguous argument 'refs/heads/MAIN refs/heads/PHD_0_2 refs/heads/PHD_0_4 refs/heads/PHD_1_1 refs/heads/PHD_ENTERPRISE refs/heads/RESTRUCTURE refs/heads/master refs/heads/rsync': unknown revision or path not in the working tree. remote: Use '--' to separate paths from revisions remote: Attempting to push to mirror remote: To g...@github.com:php/phd.git remote: * [new branch] PHD_1_1 - PHD_1_1 To g...@git.php.net:/phd.git * [new branch] PHD_1_1 - PHD_1_1 -Hannes Hi! This could happen if you have a branch and a tag with same names. Karma script should note that situation. -- Regards, Shein Alexey
Re: [PHP-DEV] Creating an RFC: do I need to be blessed somehow?
hi Tom, please try again. On Sun, Apr 8, 2012 at 4:22 PM, Tom Boutell t...@punkave.com wrote: Hi folks, I'm attempting to create an RFC on wiki.php.net but I don't get a create this page button. Is this the right place for me to start an RFC? 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 -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tokyo/Kyoto Cabinet in 5.4
On 30/09/11 12:37, Hannes Magnusson wrote: Tokyo Cabinet support was added to ext/dba recently.. but Tokyo Cabinet is about to die these days, and getting replaced with Kyoto Cabinet. Shouldn't we drop tokyo cabinet support, before we ever make a stable release with it, so we don't have to maintain it? Preferably replace it with Kyoto Cabinet support I suppose. Is it actually dead? [1] still states: I'll maintain the both of Tokyo Cabinet and Kyoto Cabinet because their values are different, as well as noting that Tokyo Cabinet is quicker in the single-threaded case. Given that both are maintained, as far as I can tell, as Tokyo Cabinet is quicker in the single-threaded case, as most PHP applications are, there is no reason to remove it. All for adding Kyoto Cabinet support, though. /gsnedders [1]: http://fallabs.com/kyotocabinet/spex.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Creating an RFC: do I need to be blessed somehow?
Thanks, I have access now. Do I need to have a patch in hand before publicizing an RFC? On Sun, Apr 8, 2012 at 10:56 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Sun, Apr 8, 2012 at 4:22 PM, Tom Boutell t...@punkave.com wrote: Hi folks, I'm attempting to create an RFC on wiki.php.net but I don't get a create this page button. Is this the right place for me to start an RFC? Thanks. Hi, could somebody with wiki admin access give Tom rfc karma? thanks! -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- 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] Tokyo/Kyoto Cabinet in 5.4
On 08/04/12 16:03, Geoffrey Sneddon wrote: Is it actually dead? [1] still states: I'll maintain the both of Tokyo Cabinet and Kyoto Cabinet because their values are different, as well as noting that Tokyo Cabinet is quicker in the single-threaded case. Given that both are maintained, as far as I can tell, as Tokyo Cabinet is quicker in the single-threaded case, as most PHP applications are, there is no reason to remove it. I don't believe Tokyo is dead, either. I've got half a patch for Kyoto support too, so I'll send that along when it's working. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: source files without opening tag
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
[PHP-DEV] [PATCH][Discussion] Ensure property name a valid label and properly handle array2object conversionReq for bugfix review.
Hi, folks:
Recently I have been trying to fix bugs on bugs.php.net. I've been looking at
the bug: https://bugs.php.net/bug.php?id=61655.
for short: after convert a stdClass with a property with number name to array
can't be access anymore.
after some code searching, I found that. class property lookup differs from
array's. when convert the
internal HashTable won't be touched. class property always lookup by string,
but array will try to handle
numeric(@see Zend/zend_hash.h:307 ZEND_HANDLE_NUMERIC macro).
I don't know whether this has been discussed before, if so forgive me please.
now PHP allow to access property with this syntax: $obj-{$expr} $expr can be
anything. PHP
didn't try to validate whether it is a valid label or not. the only problem is
we can't access it directly
like: $expr = '007gun'; $obj-{$expr} = 10; echo $obj-007gun; It's not a big
problem, we can still access
it with the same syntax. but after convert to array, we got problem.
On the contrary array to object conversion have the same problem:
?php
$ar = array(0 = value, 000invlidlabel = 2, key = value2);
$obj = (object)$ar;
$obj-0 will never be accessible, 000invilidlabel can be access, but can't
use normal property access syntax.
I know PHP make use of HashTable a lot, maybe because of performance concern or
historical reason.
but we always want to be better.
In my opinion:
1. I see no reason why user will set an invalid label as property name. because
It can be access with $obj-{$expr} only or sometime can never been accessed.
2. for the same reason array to object should at least let developer know
something they may not want to happen did happened.
so I make some change:
1. set a property name should be valid label(__set magic method also follow it)
2. raise warning and move invlid property names to a special property when
convert a array contains invlid key name to stdClass.
I just want to make things more consist, or maybe we just make sure numeric
keys works consist since php is so flexible.
Any thoughts?
BTW: I sent bugfix for bug#61347 ArrayIterator misrewind and gives misleading
notice when manipulating empty/moved to end array
https://github.com/php/php-src/pull/38 thanks @nikic @cataphract's great
suggestions, will someone take a look, do I still have to improve it?
Thank you!
--
reeze | reeze.cn
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] how do you create a private property as an array in a class
On Sun, Apr 8, 2012 at 2:26 AM, Derick Rethans der...@php.net wrote:
On Sat, 7 Apr 2012, Matthew Hernandez wrote:
How can I valgrind my extension? Google isn't bringing up many php
extension topics :/
On the shell:
export USE_ZEND_ALLOC=0
export ZEND_DONT_UNLOAD_MODULES=1
valgrind php -dextension=yourextension.so yourscript.php
See for some more info here:
http://derickrethans.nl/valgrinding-shared-modules.html
thanks, this solved the seg fault issue in no time.
I can't figure out why I keep getting a seg fault:
typedef struct _foo_object {
zend_object std;
zval *elements;
} foo_object;
static foo_object *foo_object_ptr;
You really want to avoid real globals like this though, as it makes
things not thread-safe.
thanks, I'll avoid doing it like this.
Which reminds me. Would you happen to have a best practices for
php-extension development that I could reference? I've found a few articles
around, mostly out dated.
Also, please don't top-reply on this list.
sorry.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Re: [PHP-DEV] Creating an RFC: do I need to be blessed somehow?
On Sun, Apr 8, 2012 at 4:23 PM, Tom Boutell t...@punkave.com wrote: Thanks, I have access now. Do I need to have a patch in hand before publicizing an RFC? No Tom, feel free to draft up your RFC, people will not necessarily be voting on your patch but on the concept of it. If the RFC voting consensus is negative (against) then there is no need to consider reviewing a patch. Hope this helps, feel free to ask more questions. - Paul. On Sun, Apr 8, 2012 at 10:56 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Sun, Apr 8, 2012 at 4:22 PM, Tom Boutell t...@punkave.com wrote: Hi folks, I'm attempting to create an RFC on wiki.php.net but I don't get a create this page button. Is this the right place for me to start an RFC? Thanks. Hi, could somebody with wiki admin access give Tom rfc karma? thanks! -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- 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] PHP class files without ?php at the top
Hi,
You are missing my points.
2012/4/8 Ángel González keis...@gmail.com:
2012/4/8, Yasuo Ohgaki:
2012/4/8 Ángel González keis...@gmail.com:
How does it help security?
If any, requiring '?php' before executable code makes easier to filter
out malicious files on apps with uploads in case there's a local
inclusion vulnerability somewhere.
Attackers may inject PHP script almost anything/anywhere since
PHP code may be embed anywhere in a file.
For example, malicious PHP script may be in GIF something like
gif89a ...any data.. ?php exec('rm -rf /') ?
and all attacker have to do is include/require the data somehow.
Attacker cannot do that this for other languages, since they are
not a embedded language. I know case that attackers may inject
malicious perl/ruby script in data files, but PHP is too easy
compare to these languages.
Regards,
--
Yasuo Ohgaki
Yes, but if I properly check that there's no '?php' in the uploaded files
(as you should verify everything you allow users to upload), it can't be
exploited.
OTOH if the vulnerable include is not an include but an include_code,
they could
use a file which was
Checking ?php is not enough obviously.
One should check ? and % also and there are many data
files that may contain ? and %.
Embedding PHP script in image file is popular attack method.
There is even program called image fight that inject ?php die()?
into uploaded images to prevent hosting malware images.
Attacker may inject PHP script into anywhere/any file. Disabling
embed mode is simple and effective countermeasure.
exec(rm -rf); // Example of what not to do
And was happily uploaded as plain text.
There are 2 types of attacks, one is directly uploading PHP script.
Another is include PHP script. Uploading as plain text does not help.
Regards,
--
Yasuo Ohgaki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without ?php at the top
2012/4/9 Yasuo Ohgaki yohg...@ohgaki.net:
Hi,
You are missing my points.
2012/4/8 Ángel González keis...@gmail.com:
2012/4/8, Yasuo Ohgaki:
2012/4/8 Ángel González keis...@gmail.com:
How does it help security?
If any, requiring '?php' before executable code makes easier to filter
out malicious files on apps with uploads in case there's a local
inclusion vulnerability somewhere.
Attackers may inject PHP script almost anything/anywhere since
PHP code may be embed anywhere in a file.
For example, malicious PHP script may be in GIF something like
gif89a ...any data.. ?php exec('rm -rf /') ?
and all attacker have to do is include/require the data somehow.
Attacker cannot do that this for other languages, since they are
not a embedded language. I know case that attackers may inject
malicious perl/ruby script in data files, but PHP is too easy
compare to these languages.
Regards,
--
Yasuo Ohgaki
Yes, but if I properly check that there's no '?php' in the uploaded files
(as you should verify everything you allow users to upload), it can't be
exploited.
OTOH if the vulnerable include is not an include but an include_code,
they could
use a file which was
Checking ?php is not enough obviously.
One should check ? and % also and there are many data
files that may contain ? and %.
Embedding PHP script in image file is popular attack method.
There is even program called image fight that inject ?php die()?
into uploaded images to prevent hosting malware images.
I should not forget to mention, one should check
script language=php
also.
--
Yasuo Ohgaki
yohg...@ohgaki.net
Attacker may inject PHP script into anywhere/any file. Disabling
embed mode is simple and effective countermeasure.
exec(rm -rf); // Example of what not to do
And was happily uploaded as plain text.
There are 2 types of attacks, one is directly uploading PHP script.
Another is include PHP script. Uploading as plain text does not help.
Regards,
--
Yasuo Ohgaki
--
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
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 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
Re: [PHP-DEV] PHP class files without ?php at the top
8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki yohg...@ohgaki.netнаписал:
2012/4/8 Ángel González keis...@gmail.com:
On 07/04/12 22:48, Yasuo Ohgaki wrote:
Hi,
The only valid reason for removing ?php from PHP script would be
security.
Since the null byte detection for fopen, remote/local script inclusion
became much harder than before. However, it's still possible and very
easy compare to other languages. Script execution is critical security
problem and it's worth to make it better.
If there is a switch that turns off PHP's template engine nature, PHP
could be more secure than now.
php.ini
template_mode = on ; INI_ALL On by default
php -t foo.php # template mode by default
php -T foo.php # template mode off
People has option to make their code a little secure than now
or stick with current behavior.
Regards,
How does it help security?
If any, requiring '?php' before executable code makes easier to filter
out malicious files on apps with uploads in case there's a local
inclusion vulnerability somewhere.
Attackers may inject PHP script almost anything/anywhere since
PHP code may be embed anywhere in a file.
For example, malicious PHP script may be in GIF something like
gif89a ...any data.. ?php exec('rm -rf /') ?
and all attacker have to do is include/require the data somehow.
Attacker cannot do that this for other languages, since they are
not a embedded language. I know case that attackers may inject
malicious perl/ruby script in data files, but PHP is too easy
compare to these languages.
Regards,
--
Yasuo Ohgaki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Improperly configured WEB server is not the reason to change the most basic
part of the language that will break every damn application out there.
Re: [PHP-DEV] RFC: source files without opening tag
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 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 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
Re: [PHP-DEV] PHP class files without ?php at the top
Hi,
2012/4/9 Arvids Godjuks arvids.godj...@gmail.com:
8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki yohg...@ohgaki.netнаписал:
2012/4/8 Ángel González keis...@gmail.com:
On 07/04/12 22:48, Yasuo Ohgaki wrote:
Hi,
The only valid reason for removing ?php from PHP script would be
security.
Since the null byte detection for fopen, remote/local script inclusion
became much harder than before. However, it's still possible and very
easy compare to other languages. Script execution is critical security
problem and it's worth to make it better.
If there is a switch that turns off PHP's template engine nature, PHP
could be more secure than now.
php.ini
template_mode = on ; INI_ALL On by default
php -t foo.php # template mode by default
php -T foo.php # template mode off
People has option to make their code a little secure than now
or stick with current behavior.
Regards,
How does it help security?
If any, requiring '?php' before executable code makes easier to filter
out malicious files on apps with uploads in case there's a local
inclusion vulnerability somewhere.
Attackers may inject PHP script almost anything/anywhere since
PHP code may be embed anywhere in a file.
For example, malicious PHP script may be in GIF something like
gif89a ...any data.. ?php exec('rm -rf /') ?
and all attacker have to do is include/require the data somehow.
Attacker cannot do that this for other languages, since they are
not a embedded language. I know case that attackers may inject
malicious perl/ruby script in data files, but PHP is too easy
compare to these languages.
Regards,
--
Yasuo Ohgaki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Improperly configured WEB server is not the reason to change the most basic
part of the language that will break every damn application out there.
This is not an configuration issue, but a security vulnerability that
can simply closed by disabling embed mode.
As I mentioned already, injecting malformed PHP scripts into files
is too easy compare to other languages. This could be improved
by simple modification and we can maintain compatibility with it.
I don't see anything wrong here.
Yet another PHP script injection example.
There are many applications that store user inputs in $_SESSION.
Attacker can inject PHP script into $_SESSION, then locally include
it. This is easy since attacker knew their session ID and path to
session file is can be guessed easily. All attacker has to do is
finding a vulnerable include()/require() to attack.
Regards,
--
Yasuo Ohgaki
--
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
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 yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: I have written an RFC proposing backwards-compatible support for source files without an opening ?php tag: https://wiki.php.net/rfc/source_files_without_opening_tag This RFC is not yet listed at https://wiki.php.net/rfc. I am not 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 -- 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
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 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 yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: I have written an RFC proposing backwards-compatible support for source files without an opening ?php tag: https://wiki.php.net/rfc/source_files_without_opening_tag This RFC is not yet listed at https://wiki.php.net/rfc. I am not 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without ?php at the top
Vulnerabilities in include/require should be fixed there, IMHO, not by
limiting the feature set of the language.
On Sun, Apr 8, 2012 at 5:34 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi,
2012/4/9 Arvids Godjuks arvids.godj...@gmail.com:
8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki yohg...@ohgaki.netнаписал:
2012/4/8 Ángel González keis...@gmail.com:
On 07/04/12 22:48, Yasuo Ohgaki wrote:
Hi,
The only valid reason for removing ?php from PHP script would be
security.
Since the null byte detection for fopen, remote/local script inclusion
became much harder than before. However, it's still possible and very
easy compare to other languages. Script execution is critical security
problem and it's worth to make it better.
If there is a switch that turns off PHP's template engine nature, PHP
could be more secure than now.
php.ini
template_mode = on ; INI_ALL On by default
php -t foo.php # template mode by default
php -T foo.php # template mode off
People has option to make their code a little secure than now
or stick with current behavior.
Regards,
How does it help security?
If any, requiring '?php' before executable code makes easier to filter
out malicious files on apps with uploads in case there's a local
inclusion vulnerability somewhere.
Attackers may inject PHP script almost anything/anywhere since
PHP code may be embed anywhere in a file.
For example, malicious PHP script may be in GIF something like
gif89a ...any data.. ?php exec('rm -rf /') ?
and all attacker have to do is include/require the data somehow.
Attacker cannot do that this for other languages, since they are
not a embedded language. I know case that attackers may inject
malicious perl/ruby script in data files, but PHP is too easy
compare to these languages.
Regards,
--
Yasuo Ohgaki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Improperly configured WEB server is not the reason to change the most basic
part of the language that will break every damn application out there.
This is not an configuration issue, but a security vulnerability that
can simply closed by disabling embed mode.
As I mentioned already, injecting malformed PHP scripts into files
is too easy compare to other languages. This could be improved
by simple modification and we can maintain compatibility with it.
I don't see anything wrong here.
Yet another PHP script injection example.
There are many applications that store user inputs in $_SESSION.
Attacker can inject PHP script into $_SESSION, then locally include
it. This is easy since attacker knew their session ID and path to
session file is can be guessed easily. All attacker has to do is
finding a vulnerable include()/require() to attack.
Regards,
--
Yasuo Ohgaki
--
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
Moriyoshi was kidding, as near as I can tell (: To take it at face value though, the *cough* April 1st *cough* proposal of Moriyoshi calls for the complete abolition of the feature with no backwards compatibility with existing code that uses PHP as a template language... including most popular frameworks that sensibly obey a separation between class files and template files but still use PHP rather than a dedicated templating language for templates. I don't think that's realistic (and neither did the author it appears). Since PHP's usability as a template language may conceivably be improved by other proposals, it is undesirable as well even if you don't currently find PHP to be a suitable template language. Please read my proposal over carefully as it does address the obvious issues that make Moriyoshi's proposal possibly less than serious in intent (: I would oppose a php.ini flag for this as that gives us two incompatible versions of the current version of the language to worry about and makes the feature effectively unusable in reusable code. This approach has created problems before. On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, There is RFC that is written by Moriyoshi. It's not listed in RFC page, though. https://wiki.php.net/rfc/nophptags I think these should be merged. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Yasuo Ohgaki yohg...@ohgaki.net: 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 yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: I have written an RFC proposing backwards-compatible support for source files without an opening ?php tag: https://wiki.php.net/rfc/source_files_without_opening_tag This RFC is not yet listed at https://wiki.php.net/rfc. I am not 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
Re: [PHP-DEV] RFC: source files without opening tag
Hi, I talked on twitter. Yes, he is kidding, but he is serious, too. I've added the RFC to Under Discussion and added security issue description. I also added my proposal that controls embed mode. BTW, I don't think we need new require_path why don't we use require file.php, ture; or some thing similar? I prefer to use switch, since security countermeasure is better to be enforced by switch. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: Moriyoshi was kidding, as near as I can tell (: To take it at face value though, the *cough* April 1st *cough* proposal of Moriyoshi calls for the complete abolition of the feature with no backwards compatibility with existing code that uses PHP as a template language... including most popular frameworks that sensibly obey a separation between class files and template files but still use PHP rather than a dedicated templating language for templates. I don't think that's realistic (and neither did the author it appears). Since PHP's usability as a template language may conceivably be improved by other proposals, it is undesirable as well even if you don't currently find PHP to be a suitable template language. Please read my proposal over carefully as it does address the obvious issues that make Moriyoshi's proposal possibly less than serious in intent (: I would oppose a php.ini flag for this as that gives us two incompatible versions of the current version of the language to worry about and makes the feature effectively unusable in reusable code. This approach has created problems before. On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, There is RFC that is written by Moriyoshi. It's not listed in RFC page, though. https://wiki.php.net/rfc/nophptags I think these should be merged. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Yasuo Ohgaki yohg...@ohgaki.net: 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 yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: I have written an RFC proposing backwards-compatible support for source files without an opening ?php tag: https://wiki.php.net/rfc/source_files_without_opening_tag This RFC is not yet listed at https://wiki.php.net/rfc. I am not 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 -- 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
Thanks. However, would you please fix the summary on the RFC's page to match the summary in the actual RFC? As you have written it, it implies that support for ?php would be completely removed. This is not the case. As for adding a boolean parameter to the require keyword, as the RFC mentions there are already at least two distinctions already when requiring files in PHP: * include vs. require behavior (warning vs. error on failure) * once vs. every time (require_once vs. require) And we are proposing a third: * start in php mode vs. start in html mode We already have four keywords for requiring files. At this point it does not make sense to keep introducing more keywords (we would need 8 with this change). Your boolean flag proposal keeps it to four keywords, but as soon as someone adds another flag it will become awkward to remember them. Since PHP does not have named parameters I think an associative array is the best way to go (especially with the new short syntax). Also I don't think it makes sense to forbid shifting into html mode later in the file, it could reduce support for the proposal needlessly - since it already lets people who want to write clean all-PHP files do so, and some of those people might have legitimate reasons to use HTML mode in the scope of a function or method (where it does not suddenly introduce whitespace without being explicitly called, etc). But if it really came down to it I could live with an absolutely nothing but PHP behavior when the code flag is true (supporting ?php when the flag is not set is a must of course). On Sun, Apr 8, 2012 at 6:45 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, I talked on twitter. Yes, he is kidding, but he is serious, too. I've added the RFC to Under Discussion and added security issue description. I also added my proposal that controls embed mode. BTW, I don't think we need new require_path why don't we use require file.php, ture; or some thing similar? I prefer to use switch, since security countermeasure is better to be enforced by switch. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: Moriyoshi was kidding, as near as I can tell (: To take it at face value though, the *cough* April 1st *cough* proposal of Moriyoshi calls for the complete abolition of the feature with no backwards compatibility with existing code that uses PHP as a template language... including most popular frameworks that sensibly obey a separation between class files and template files but still use PHP rather than a dedicated templating language for templates. I don't think that's realistic (and neither did the author it appears). Since PHP's usability as a template language may conceivably be improved by other proposals, it is undesirable as well even if you don't currently find PHP to be a suitable template language. Please read my proposal over carefully as it does address the obvious issues that make Moriyoshi's proposal possibly less than serious in intent (: I would oppose a php.ini flag for this as that gives us two incompatible versions of the current version of the language to worry about and makes the feature effectively unusable in reusable code. This approach has created problems before. On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, There is RFC that is written by Moriyoshi. It's not listed in RFC page, though. https://wiki.php.net/rfc/nophptags I think these should be merged. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Yasuo Ohgaki yohg...@ohgaki.net: 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 yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: I have written an RFC proposing backwards-compatible support for source files without an opening ?php tag: https://wiki.php.net/rfc/source_files_without_opening_tag This RFC is not yet listed at https://wiki.php.net/rfc. I am not 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
Re: [PHP-DEV] RFC: source files without opening tag
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. As for adding a boolean parameter to the require keyword, as the RFC mentions there are already at least two distinctions already when requiring files in PHP: * include vs. require behavior (warning vs. error on failure) * once vs. every time (require_once vs. require) And we are proposing a third: * start in php mode vs. start in html mode We already have four keywords for requiring files. At this point it does not make sense to keep introducing more keywords (we would need 8 with this change). Your boolean flag proposal keeps it to four keywords, but as soon as someone adds another flag it will become awkward to remember them. Since PHP does not have named parameters I think an associative array is the best way to go (especially with the new short syntax). Also I don't think it makes sense to forbid shifting into html mode later in the file, it could reduce support for the proposal needlessly - since it already lets people who want to write clean all-PHP files do so, and some of those people might have legitimate reasons to use HTML mode in the scope of a function or method (where it does not suddenly introduce whitespace without being explicitly called, etc). But if it really came down to it I could live with an absolutely nothing but PHP behavior when the code flag is true (supporting ?php when the flag is not set is a must of course). On Sun, Apr 8, 2012 at 6:45 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, I talked on twitter. Yes, he is kidding, but he is serious, too. I've added the RFC to Under Discussion and added security issue description. I also added my proposal that controls embed mode. BTW, I don't think we need new require_path why don't we use require file.php, ture; or some thing similar? I prefer to use switch, since security countermeasure is better to be enforced by switch. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: Moriyoshi was kidding, as near as I can tell (: To take it at face value though, the *cough* April 1st *cough* proposal of Moriyoshi calls for the complete abolition of the feature with no backwards compatibility with existing code that uses PHP as a template language... including most popular frameworks that sensibly obey a separation between class files and template files but still use PHP rather than a dedicated templating language for templates. I don't think that's realistic (and neither did the author it appears). Since PHP's usability as a template language may conceivably be improved by other proposals, it is undesirable as well even if you don't currently find PHP to be a suitable template language. Please read my proposal over carefully as it does address the obvious issues that make Moriyoshi's proposal possibly less than serious in intent (: I would oppose a php.ini flag for this as that gives us two incompatible versions of the current version of the language to worry about and makes the feature effectively unusable in reusable code. This approach has created problems before. On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, There is RFC that is written by Moriyoshi. It's not listed in RFC page, though. https://wiki.php.net/rfc/nophptags I think these should be merged. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Yasuo Ohgaki yohg...@ohgaki.net: 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 yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: I have written an RFC proposing backwards-compatible support for source files without an opening ?php tag: https://wiki.php.net/rfc/source_files_without_opening_tag This RFC is not yet listed at https://wiki.php.net/rfc. I am not 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:
Re: [PHP-DEV] RFC: source files without opening tag
Hi, I modified the title. * include vs. require behavior (warning vs. error on failure) * once vs. every time (require_once vs. require) And we are proposing a third: Then, better name would be require_script()/include_script(). However, this option will not solve script inclusion security issues. Fixing security issues will not have much opposition, but adding new syntax will. I like embedded languages, but programmers can write vulnerable code with it. Embed feature is better to be controlled by programmers/ administrators for better security. Regards, P.S. I'm uncomfortable with current PHP, since someone may write include $_GET['module'] or like for my systems. This code raises fatal security issue with current PHP, but it's not with my proposal. -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: Thanks. However, would you please fix the summary on the RFC's page to match the summary in the actual RFC? As you have written it, it implies that support for ?php would be completely removed. This is not the case. As for adding a boolean parameter to the require keyword, as the RFC mentions there are already at least two distinctions already when requiring files in PHP: * include vs. require behavior (warning vs. error on failure) * once vs. every time (require_once vs. require) And we are proposing a third: * start in php mode vs. start in html mode We already have four keywords for requiring files. At this point it does not make sense to keep introducing more keywords (we would need 8 with this change). Your boolean flag proposal keeps it to four keywords, but as soon as someone adds another flag it will become awkward to remember them. Since PHP does not have named parameters I think an associative array is the best way to go (especially with the new short syntax). Also I don't think it makes sense to forbid shifting into html mode later in the file, it could reduce support for the proposal needlessly - since it already lets people who want to write clean all-PHP files do so, and some of those people might have legitimate reasons to use HTML mode in the scope of a function or method (where it does not suddenly introduce whitespace without being explicitly called, etc). But if it really came down to it I could live with an absolutely nothing but PHP behavior when the code flag is true (supporting ?php when the flag is not set is a must of course). On Sun, Apr 8, 2012 at 6:45 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, I talked on twitter. Yes, he is kidding, but he is serious, too. I've added the RFC to Under Discussion and added security issue description. I also added my proposal that controls embed mode. BTW, I don't think we need new require_path why don't we use require file.php, ture; or some thing similar? I prefer to use switch, since security countermeasure is better to be enforced by switch. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: Moriyoshi was kidding, as near as I can tell (: To take it at face value though, the *cough* April 1st *cough* proposal of Moriyoshi calls for the complete abolition of the feature with no backwards compatibility with existing code that uses PHP as a template language... including most popular frameworks that sensibly obey a separation between class files and template files but still use PHP rather than a dedicated templating language for templates. I don't think that's realistic (and neither did the author it appears). Since PHP's usability as a template language may conceivably be improved by other proposals, it is undesirable as well even if you don't currently find PHP to be a suitable template language. Please read my proposal over carefully as it does address the obvious issues that make Moriyoshi's proposal possibly less than serious in intent (: I would oppose a php.ini flag for this as that gives us two incompatible versions of the current version of the language to worry about and makes the feature effectively unusable in reusable code. This approach has created problems before. On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, There is RFC that is written by Moriyoshi. It's not listed in RFC page, though. https://wiki.php.net/rfc/nophptags I think these should be merged. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Yasuo Ohgaki yohg...@ohgaki.net: 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 yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: I have written an RFC proposing backwards-compatible support for source files without an opening ?php tag:
