Hi!
5.4.1 will be the first release we're releasing using our new git setup.
I would like to refine a process that we used to have for releases and
make small tweaks hopefully to allow us more predictable release
schedule and faster releases.
What I am proposing is the following:
1. At the start o
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 except
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 secur
Tom,
On Sun, Apr 8, 2012 at 4:14 PM, Tom Boutell 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 not the case.
>
> As for adding a boolean parameter to the require keywor
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 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
>
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
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 fra
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 wrote:
> Hi,
>
> 2012/4/9 Arvids Godjuks :
>> 8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki написал:
>>
>>> 2012/4/8 Ángel González :
>>>
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 :
> Hi,
>
> Moriyoshi has created same entry on 4/1, but
> it seems it was
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...@ohga
Hi,
2012/4/9 Arvids Godjuks :
> 8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki написал:
>
>> 2012/4/8 Ángel González :
>> > On 07/04/12 22:48, Yasuo Ohgaki wrote:
>> >> Hi,
>> >>
>> >> The only valid reason for removing > >> security.
>> >>
>> >> Since the null byte detection for fopen, remote/lo
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 wrote:
> As far as I know, you've already met that req by posting the RFC
8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki написал:
> 2012/4/8 Ángel González :
> > On 07/04/12 22:48, Yasuo Ohgaki wrote:
> >> Hi,
> >>
> >> The only valid reason for removing >> security.
> >>
> >> Since the null byte detection for fopen, remote/local script inclusion
> >> became much hard
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" wrote:
> I have written an RFC proposing backwards-com
2012/4/9 Yasuo Ohgaki :
> Hi,
>
> You are missing my points.
>
> 2012/4/8 Ángel González :
>> 2012/4/8, Yasuo Ohgaki:
>>> 2012/4/8 Ángel González :
How does it help security?
If any, requiring '>>> out malicious files on apps with uploads in case there's a local
inclusion vulnerabili
Hi,
You are missing my points.
2012/4/8 Ángel González :
> 2012/4/8, Yasuo Ohgaki:
>> 2012/4/8 Ángel González :
>>> How does it help security?
>>> If any, requiring '>> out malicious files on apps with uploads in case there's a local
>>> inclusion vulnerability somewhere.
>>>
>> Attackers may inj
On Sun, Apr 8, 2012 at 4:23 PM, Tom Boutell 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 neg
On Sun, Apr 8, 2012 at 2:26 AM, Derick Rethans 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 -d
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 proper
I have written an RFC proposing backwards-compatible support for
source files without an opening 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"
sessi
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 a
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 wrote:
>
>
> On Sun, Apr 8, 2012 at 4:22 PM, Tom Boutell wrote:
>>
>> Hi folks, I'm attempting to create an RFC on wiki.php.net but I don't
>> get a "create thi
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 main
hi Tom,
please try again.
On Sun, Apr 8, 2012 at 4:22 PM, Tom Boutell 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
> p
суббота, 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 br
He registered a wiki account already.
2012.04.08. 16:27, "Pierre Joye" 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 wrote:
> > Hi folks, I'm attempting to create an RFC on wiki.php.net but I don't
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 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 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 unsub
On Sun, 08 Apr 2012 01:38:46 +0100, Stas Malyshev
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 documentatio
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 wrote:
> 2012/4/8, Yasuo Ohgaki:
>> 2012/4/8 Ángel Gonzá
2012/4/8, Yasuo Ohgaki:
> 2012/4/8 Ángel González :
>> How does it help security?
>> If any, requiring '> 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 embe
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:
32 matches
Mail list logo
