2016-09-21 8:54 GMT+02:00 Yasuo Ohgaki <yohg...@ohgaki.net>:
> Hi Stas,
> On Wed, Sep 21, 2016 at 11:26 AM, Stanislav Malyshev
> <smalys...@gmail.com> wrote:
> >> I think we are better to limit max collisions.
> >> I'm +1 for Nikita's proposal does this.
> > Max collision per what? How much would be the limit?
> Collision by keys.
> It would be nice to have configurable limit like regex stack/backtrack
> That said, wouldn't 1000 enough for almost all apps?
Having a limit isn't a good idea for all use cases, but it works for some.
> Anyway, we have two choices
> - Simply limit the number of collisions. (Fast and has no impact to code)
It totally has impact to code. What happens if we have enough collisions?
Throw an exception? Might break code, any array insert operation might
suddenly fail. Simply fatal? Not suitable for long running applications
like Aerys (https://github.com/amphp/aerys) or PPM (
I guess to support these use cases, we have to switch to a cryptographic
hash function here. But I guess it would be totally fine having such a
feature as compile flag, limiting the number of collisions usually and
provide a cryptographic hash function for long running apps to protect them.
I think such an option is fine for those running long running applications,
since they don't rely on setups like shared hosting and can usually compile
their own versions.
> - Use crypt safe hash and salt. (Slow and has impact to opcache/etc)
Do we need a salt here? If not, how does it then impact opcache?
> Limiting something is good to have sometimes.
> Python even limits number of recursions to 1000 by default.
Recursion is / should not be affected by user input and thus is a slightly
> We have PCRE stack/backtrack limits. (We'll have mbregex stack limit soon)
> Collision limit is good one also.
> Yasuo Ohgaki
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php