On 22 September 2016 00:23:16 BST, Stanislav Malyshev
wrote:
>In which case some limit like 1000 (just random number but can be
>tested) would probably be OK. The question now is would it be enough to
>block DoS? I.e. if we construct data to cause 999 collisions each time
>to stay just under the
On 22 Sep 2016 00:43, "Stanislav Malyshev" wrote:
>
> Hi!
>
> > As linked in my first reply, there was a previous discussion on the
> > topic: http://markmail.org/message/ttbgcvdu4f7uymfb
> > The collision-counting approach that Yasuo references is linked at the
> > start of the first mail: https:
On 22/09/2016 08:52, Jakub Zelenka wrote:
I don't like the initial version of the patch that was causing fatal error
for json_decode. That's not how json_decode should work. I think that Bob
came up later with a better version that was using json recursion error. It
might require a bit more work
On Thu, Sep 22, 2016 at 10:06 AM, Rowan Collins
wrote:
> On 22/09/2016 08:52, Jakub Zelenka wrote:
>
>> I don't like the initial version of the patch that was causing fatal error
>> for json_decode. That's not how json_decode should work. I think that Bob
>> came up later with a better version th
On 22/09/2016 10:48, Jakub Zelenka wrote:
Nope the point of the Bob's patch is to use graceful handling with
exception that can be easily checked by the json parser for example! See
https://github.com/php/php-src/pull/1706
Ah, I stand corrected, I hadn't seen that version referenced before.
A
Results for project PHP master, build date 2016-09-22 06:24:56+03:00
commit: 923d695
previous commit:ea52b84
revision date: 2016-09-21 16:24:15-04:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On Thu, Sep 22, 2016 at 10:54 AM, Rowan Collins
wrote:
> On 22/09/2016 10:48, Jakub Zelenka wrote:
>
>>
>> Nope the point of the Bob's patch is to use graceful handling with
>> exception that can be easily checked by the json parser for example! See
>> https://github.com/php/php-src/pull/1706
>>
2016-09-22 20:10 GMT+02:00 Jakub Zelenka :
> On Thu, Sep 22, 2016 at 10:54 AM, Rowan Collins
> wrote:
>
> > On 22/09/2016 10:48, Jakub Zelenka wrote:
> >
> >>
> >> Nope the point of the Bob's patch is to use graceful handling with
> >> exception that can be easily checked by the json parser for e
On Thu, Sep 22, 2016 at 8:13 PM, Niklas Keller wrote:
> 2016-09-22 20:10 GMT+02:00 Jakub Zelenka :
>
>> On Thu, Sep 22, 2016 at 10:54 AM, Rowan Collins
>> wrote:
>>
>> > On 22/09/2016 10:48, Jakub Zelenka wrote:
>> >
>> >>
>> >> Nope the point of the Bob's patch is to use graceful handling with
Is the XML api also affected by hashdos?
cheers, glenn
On Thursday, 22 September 2016, Jakub Zelenka wrote:
> On Thu, Sep 22, 2016 at 8:13 PM, Niklas Keller > wrote:
>
> > 2016-09-22 20:10 GMT+02:00 Jakub Zelenka >:
> >
> >> On Thu, Sep 22, 2016 at 10:54 AM, Rowan Collins <
> rowan.coll...@gma
Hi!
> Yeah it introduces new functions for updating hash which is used by json
> for updating array and it's also in std object handler which is used when
> updating json object. For some other bits like updating array, it will stay
> with fatal. The thing is that json parser can then easily check
> What still worries me personally is ===. What do you think would be the
> least incorrect way to handle ===
> 2) === is not affected by strict_comparisons.
I think not changing it is the correct thing to do.but I think it
needs more thinking about.
Btw, the RFC would need to cover all cases
> Am 22.9.2016 um 22:08 schrieb Stanislav Malyshev :
>
> Hi!
>
>> Yeah it introduces new functions for updating hash which is used by json
>> for updating array and it's also in std object handler which is used when
>> updating json object. For some other bits like updating array, it will stay
>
Hi!
> The patch is not only targeting JSON. He just used JSON as an example.
>
> Every function generating arrays with keys based on user-defined input
> needs to be updated.
That looks like a very good way to make a lot of mistakes, miss a lot of
cases and end up playing whack-a-mole with cover
Adding the RMs.
Dacey, I think this needs a deeper look and decision.
On Sep 22, 2016 7:51 AM, "Pierre Joye" wrote:
>
> On Sep 22, 2016 1:07 AM, "Levi Morrison" wrote:
> >
> > On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas
> > wrote:
> > >> To handle this in code written around current __toS
15 matches
Mail list logo
