On Mon, 09 Jan 2012 04:59:09 +0100, Paul Dragoonis dragoo...@gmail.com
wrote:
Hey Internals,
I've finished the patch, and with approval i'd like to push to trunk,
even though i'm aware we have a 5_4 branch code freeze.
Can someone review my work and provide feedback/approval?
[1]
On Mon, Jan 9, 2012 at 9:17 AM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote:
On Mon, 09 Jan 2012 04:59:09 +0100, Paul Dragoonis dragoo...@gmail.com
wrote:
Hey Internals,
I've finished the patch, and with approval i'd like to push to trunk,
even though i'm aware we have a 5_4 branch code
On Wed, Nov 16, 2011 at 12:30 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Wed, Nov 16, 2011 at 12:12 PM, Michael Wallner m...@php.net wrote:
On Tue, 15 Nov 2011 23:51:25 +0100, Patrick ALLAERT wrote:
As per rfc6265, it seems incorrect:
Servers SHOULD NOT include more than one
pls add it to the RFC, the right one as this one is a 404.
On Mon, Jan 9, 2012 at 2:58 AM, Tom Worster f...@thefsb.org wrote:
I forgot the URL: https://github.com/tom--/php-cs_random_bytesemo
:X
tom
On 1/8/12 8:56 PM, Tom Worster f...@thefsb.org wrote:
I have also set up a github repo
I added it at the top, I hope that's ok.
the URL is https://github.com/tom--/php-cs_random_bytes
Thanks for pointing that out
Tom
On 1/9/12 7:54 AM, Pierre Joye pierre@gmail.com wrote:
pls add it to the RFC, the right one as this one is a 404.
On Mon, Jan 9, 2012 at 2:58 AM, Tom Worster
Thanks for the feedback Gustavo.
New patch is here: https://gist.github.com/1582997
Test case: https://gist.github.com/1583022
Comments are inline.
On Mon, Jan 9, 2012 at 8:17 AM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
On Mon, 09 Jan 2012 04:59:09 +0100, Paul Dragoonis dragoo...@gmail.com
hi,
Some comments, same as I did before:
cs means crypto safe. In your implementation, it is by no mean crypto
safe as it relies on urandom for the cases where /dev/random did not
return enough data (some OS are non blocking here), while linux is.
It should detect which entropy sources are
Pierre,
1. The proposal in the RFC is explicit: The function should neither block
nor return a failure status in the case that the systems entropy pool is
depleted. However, it should allow the caller to discover if this is the
case. etc...
2. The current code implements that by setting the
On 1/9/2012 7:50 AM, Tom Worster wrote:
Pierre,
1. The proposal in the RFC is explicit: The function should neither block
nor return a failure status in the case that the systems entropy pool is
depleted. However, it should allow the caller to discover if this is the
case. etc...
2. The
hi,
Moving this discussion here as it makes little to non sense to discuss
that any longer on security@
We are now very late behind an acceptable delay to provide a fix for
the hash DoS, to say it nicely.
I'd strongly suggest to release 5.3.9 (RC5 has been tested now) final
this week using the
On Mon, Jan 9, 2012 at 4:41 PM, Pierre Joye pierre@gmail.com wrote:
hi,
Moving this discussion here as it makes little to non sense to discuss
that any longer on security@
We are now very late behind an acceptable delay to provide a fix for
the hash DoS, to say it nicely.
I'd strongly
Dear Pierre and others,
I'd strongly suggest to release 5.3.9 (RC5 has been tested now) final
this week using the max_input_vars fix, with the modification from
Laruence (but with a larger limit). Laruence addition also fixes
serialize or json, which are parts that need this fix as well as it
Hey,
I think you accidentially sent this to me, not to the list ;) By the
way, I think you and Pierre are talking about different patches. We do
know that the hash size randomization will not work. Pierre is
referring to another patch that extends max_input_vars to
unserilized() and
Hi:
I have a new idea, which is simple and also works for Jason/serialized etc.
That is Restricting a max length of a buckets list in a hash table.
If a bucket's length exceed 1024, any insertion into this bucket
will return failure and a warning will be generated.
What do you think?
I was under the impression that somebody worked on the information
disclosure issue in the error message and the error message spamming.
This seems not to be the case.
If you, Pierre, are ready for Windows builds tomorrow morning I'd like
to release tomorrow as is.
johannes
On Mon, 2012-01-09
Hey,
That is Restricting a max length of a buckets list in a hash table.
If a bucket's length exceed 1024, any insertion into this bucket
will return failure and a warning will be generated.
What do you think?
very bad idea. Especially when it comes to numerical indices a legitimate
On Mon, Jan 9, 2012 at 5:18 PM, Stefan Esser ste...@nopiracy.de wrote:
Dear Pierre and others,
I'd strongly suggest to release 5.3.9 (RC5 has been tested now) final
this week using the max_input_vars fix, with the modification from
Laruence (but with a larger limit). Laruence addition also
Hi:
I am not sure whether you have understood my point.
If an array have more than 1024 buckets in an same bucket
list(same index), there must already be an performance issue.
Sent from my iPhone
在 2012-1-10，0:41，Stefan Esser ste...@nopiracy.de 写道：
Hey,
That is Restricting a max
On Mon, Jan 9, 2012 at 5:34 PM, Stefan Esser ste...@nopiracy.de wrote:
Of course I am biased, because suhosin is one of the affected extensions. But
that said suhosin has a limit similar to max_input_vars for 7 years now.
Not really the same, but yes. While the reasons you did it was not the
On Mon, Jan 9, 2012 at 5:36 PM, Xinchen Hui larue...@gmail.com wrote:
Hi:
I have a new idea, which is simple and also works for Jason/serialized etc.
That is Restricting a max length of a buckets list in a hash table.
If a bucket's length exceed 1024, any insertion into this bucket
hi,
No time for new ideas yet. We cannot afford to implement, test and
valid new propositions and provide a fix as soon as possible (read: in
the next days).
What's the status of your patch? The max input var one, not the random
(or derived version), can you post it in this thread again for the
Sent from my iPhone
在 2012-1-10，0:57，Pierre Joye pierre@gmail.com 写道：
hi,
No time for new ideas yet. We cannot afford to implement, test and
valid new propositions and provide a fix as soon as possible (read: in
the next days)
That idea will only need one hour to be implemented. :)
Hello Pierre,
Not really the same, but yes. While the reasons you did it was not the
same. Also the length check is not related or cannot be used for this
fix. But nice self promotion ;-)
Considering the fact that the HashDOS problem was originally discussed in a
paper 2003, someone
Hello,
I am not sure whether you have understood my point.
I understood your point: you want to break HashTables because 1024 colliding
entries could have an performance impact. This could break thousands of scripts.
for ($i=0; $i2000; $i++) $arr[$i16] = 1;
would stop working, while it
Sent from my iPhone
在 2012-1-10，1:07，Stefan Esser ste...@nopiracy.de 写道：
Hello,
I am not sure whether you have understood my point.
I understood your point: you want to break HashTables because 1024 colliding
entries could have an performance impact. This could break thousands of
On 01/09/2012 08:50 AM, Xinchen Hui wrote:
Hi:
I am not sure whether you have understood my point.
If an array have more than 1024 buckets in an same bucket
list(same index), there must already be an performance issue.
The problem is you really need to consider the source. There are
Sent from my iPhone
在 2012-1-10，1:14，Rasmus Lerdorf ras...@php.net 写道：
On 01/09/2012 08:50 AM, Xinchen Hui wrote:
Hi:
I am not sure whether you have understood my point.
If an array have more than 1024 buckets in an same bucket
list(same index), there must already be an performance
Sent from my iPhone
在 2012-1-10，1:18，Xinchen Hui larue...@gmail.com 写道：
Sent from my iPhone
在 2012-1-10，1:14，Rasmus Lerdorf ras...@php.net 写道：
On 01/09/2012 08:50 AM, Xinchen Hui wrote:
Hi:
I am not sure whether you have understood my point.
If an array have more than 1024 buckets
On 01/09/2012 09:18 AM, Xinchen Hui wrote:
Sent from my iPhone
在 2012-1-10，1:14，Rasmus Lerdorf ras...@php.net 写道：
On 01/09/2012 08:50 AM, Xinchen Hui wrote:
Hi:
I am not sure whether you have understood my point.
If an array have more than 1024 buckets in an same bucket
list(same
-Original Message-
From: Nikita Popov [mailto:nikita@googlemail.com]
Sent: Monday, January 09, 2012 11:54 AM
To: Xinchen Hui
Cc: Pierre Joye; PHP internals; Johannes Schlüter; Laruence
Subject: Re: [PHP-DEV] Re: 5.3.9, Hash DoS, release
On Mon, Jan 9, 2012 at 5:36 PM, Xinchen
On 1/9/12 10:39 AM, Thomas Hruska thru...@cubiclesoft.com wrote:
I'm glad someone is doing something about making more sources of
randomness in PHP.
I am pleased to hear it.
Instead of a 'bool', use an 'int' for $is_strong_result but more
accurately call it $result_strength. Assign a minimum
Sent from my iPhone
在 2012-1-10，1:51，Rasmus Lerdorf ras...@php.net 写道：
On 01/09/2012 09:18 AM, Xinchen Hui wrote:
Sent from my iPhone
在 2012-1-10，1:14，Rasmus Lerdorf ras...@php.net 写道：
On 01/09/2012 08:50 AM, Xinchen Hui wrote:
Hi:
I am not sure whether you have understood my point.
On 01/09/2012 05:28 PM, Xinchen Hui wrote:
I understand the difference. But large arrays are obviously the ones
that are prone to hitting the collision limits.
Yes, but don't you think this is at least better than restricting
number of elements? :)
The difference is the source. If, for
Hi,
I've tested your code and confirmed the behaviors with PHP 5.4RC4 and PHP
5.4RC5.
I think you should report this bug to bugs.php.net.
(12/01/06 5:31), Daniel Henning wrote:
Hi,
i've searched bugs database a lot but couldn't find something about this one.
Setup:
Windows Vista
PHP5.4
On Tue, Jan 10, 2012 at 12:57 AM, Pierre Joye pierre@gmail.com wrote:
hi,
No time for new ideas yet. We cannot afford to implement, test and
valid new propositions and provide a fix as soon as possible (read: in
the next days).
What's the status of your patch? The max input var one, not
On Sun, Jan 8, 2012 at 12:40 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
As we are nearing the release of 5.4.0, I'd like to ask everybody not to
commit anything to 5.4 branch without the approval of one of the RMs (myself
or David) from now until release of 5.4.0. Unless something
hi Marius,
You can do it yourself :-)
Cheers,
On Tue, Jan 10, 2012 at 7:50 AM, marius adrian popa map...@gmail.com wrote:
On Sun, Jan 8, 2012 at 12:40 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
As we are nearing the release of 5.4.0, I'd like to ask everybody not to
commit
Hi Alex,
Right now it's possible to use SOAP with proxy using special options in
SoapClient constructor
(http://www.php.net/manual/en/soapclient.soapclient.php)
new SoapClient($wsdl, array('proxy_host' = 'my.proxy.com',
'proxy_port' = '8080',
Hi geeks!
We're unable to disable the ereg extension today, yet it's been deprecated
since PHP 5.3.0. Is this by design?
Regards,
Philip
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
39 matches
Mail list logo
