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
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
> 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
>
> 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
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
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
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
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 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
>>
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 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
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 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 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 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
15 matches
Mail list logo
