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
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 Marius,
You can do it yourself :-)
Cheers,
On Tue, Jan 10, 2012 at 7:50 AM, marius adrian popa wrote:
> On Sun, Jan 8, 2012 at 12:40 AM, Stas Malyshev 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 ap
On Sun, Jan 8, 2012 at 12:40 AM, Stas Malyshev 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 critical for
> 5.4.0
On Tue, Jan 10, 2012 at 12:57 AM, Pierre Joye 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 the random
>
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
> PH
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 e
Sent from my iPhone
在 2012-1-10，1:51，Rasmus Lerdorf 写道：
> On 01/09/2012 09:18 AM, Xinchen Hui wrote:
>> Sent from my iPhone
>>
>> 在 2012-1-10，1:14，Rasmus Lerdorf 写道：
>>
>>> On 01/09/2012 08:50 AM, Xinchen Hui wrote:
Hi:
I am not sure whether you have understood my point.
On 1/9/12 10:39 AM, "Thomas Hruska" 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 recommended
>thres
> -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, X
On 01/09/2012 09:18 AM, Xinchen Hui wrote:
> Sent from my iPhone
>
> 在 2012-1-10，1:14，Rasmus Lerdorf 写道：
>
>> 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
>>> lis
Sent from my iPhone
在 2012-1-10，1:18，Xinchen Hui 写道：
> Sent from my iPhone
>
> 在 2012-1-10，1:14，Rasmus Lerdorf 写道：
>
>> 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 bucke
Sent from my iPhone
在 2012-1-10，1:14，Rasmus Lerdorf 写道：
> 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
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
Sent from my iPhone
在 2012-1-10，1:07，Stefan Esser 写道：
> 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
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; $i<2000; $i++) $arr[$i<<16] = 1;
would stop working, while it
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 discus
Sent from my iPhone
在 2012-1-10，0:57，Pierre Joye 写道：
> 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. :)
Anyone who have tim
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
r
On Mon, Jan 9, 2012 at 5:36 PM, Xinchen Hui 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
> will return fai
On Mon, Jan 9, 2012 at 5:34 PM, Stefan Esser 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
same. Also the le
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 写道：
> Hey,
>
>> That is Restricting a max length of a bucket
On Mon, Jan 9, 2012 at 5:18 PM, Stefan Esser 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 fixes
>> seri
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 legit
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 a
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?
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 json
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
On Mon, Jan 9, 2012 at 4:41 PM, Pierre Joye 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 suggest to
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 m
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 curre
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 $is
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 avail
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 wrote:
> On Mon, 09 Jan 2012 04:59:09 +0100, Paul Dragoonis
> wrote:
>
>> Hey Internals,
>>
>> I've
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" 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 wrote:
>> I forg
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 wrote:
> I forgot the URL: https://github.com/tom--/php-cs_random_bytesemo
>
> :X
>
> tom
>
> On 1/8/12 8:56 PM, "Tom Worster" wrote:
>
>>I have also set up a github repo with 4 files in it. It
On Wed, Nov 16, 2011 at 12:30 PM, Ferenc Kovacs wrote:
>
>
> On Wed, Nov 16, 2011 at 12:12 PM, Michael Wallner 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 Set-Cookie header f
On Mon, Jan 9, 2012 at 9:17 AM, Gustavo Lopes wrote:
> On Mon, 09 Jan 2012 04:59:09 +0100, Paul Dragoonis
> 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
On Mon, 09 Jan 2012 04:59:09 +0100, Paul Dragoonis
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] https://gist.github.com/15809
39 matches
Mail list logo
