Re: HashDoS
| From: | Glenn Eggleton | Date: | Thu, 22 Sep 2016 19:33:13 +0000 |
| Subject: | Re: HashDoS | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-96100@lists.php.net to get a copy of this message | ||
Is the XML api also affected by hashdos?
cheers, glenn
On Thursday, 22 September 2016, Jakub Zelenka <bukka@php.net> wrote:
> On Thu, Sep 22, 2016 at 8:13 PM, Niklas Keller <me@kelunik.com
> <javascript:;>> wrote:
>
> > 2016-09-22 20:10 GMT+02:00 Jakub Zelenka <bukka@php.net <javascript:;>>:
> >
> >> On Thu, Sep 22, 2016 at 10:54 AM, Rowan Collins <
> rowan.collins@gmail.com <javascript:;>>
> >> 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
> >> >>
> >> >
> >> > Ah, I stand corrected, I hadn't seen that version referenced before.
> >> >
> >> > Am I right in thinking that the idea here is that if the context is
> >> > exception-safe it can opt in to a more graceful handling mechanism?
> And
> >> > that if not, it will go ahead and bail out as in Niki's patch?
> >> >
> >> >
> >> 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 if there
> >> was an exception and if so, it will set JSON_ERROR_DEPTH and clear it.
> It
> >> seems much better though.
> >
> >
> > But why JSON_ERROR_DEPTH and not a new constant?
> >
> >
> Yeah I agree and I already suggested it in the PR an hour ago. ;)
>
> https://github.com/php/php-src/pull/1706#discussion_r80102953
>
> Cheers
>
> Jakub
>