Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

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 __toString seems pretty > > simple > > > > Yes it is, but that's not what we're talking about:

Re: [PHP-DEV] HashDoS

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://github.com/php/php-src/pull/1565 > > Collisions are counted

Re: [PHP-DEV] HashDoS

Hi Stas, On Thu, Sep 22, 2016 at 7:47 AM, Stanislav Malyshev wrote: >> On Wed, Sep 21, 2016 at 11:26 AM, Stanislav Malyshev >> wrote: >>> I think we are better to limit max collisions. I'm +1 for Nikita's proposal does this. >>> >>> Max

Re: [PHP-DEV] HashDoS

On Thu, Sep 22, 2016 at 1:07 AM, Stanislav Malyshev wrote: > Hi! > > >> Lets [try] to quantify the probability of reaching the collision limit C > > with a hashtable of size N and assuming a random hash distribution. The > > upper bound for this should be (N choose C) *

Re: [PHP-DEV] HashDoS

Hi! > I'm not so sure of this now - unless, again, I misunderstand what we're > counting. It just occurred to me that I possibly do misunderstand what is counted - if the proposal is to count collisions per lookup. I rerun my scripts with that assumption and turns out the longest collision

Re: [PHP-DEV] HashDoS

Hi! >> Lets [try] to quantify the probability of reaching the collision limit C > with a hashtable of size N and assuming a random hash distribution. The > upper bound for this should be (N choose C) * (1/N)^(C-1), with (1/N)^(C-1) > being the probability that C elements hash to one value and (N

Re: [PHP-DEV] HashDoS

Hi! > Hi Stas, > > On Wed, Sep 21, 2016 at 11:26 AM, Stanislav Malyshev > 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. Not sure I

Re: [PHP-DEV] HashDoS

Hi Kiklas, On Wed, Sep 21, 2016 at 5:06 PM, Niklas Keller wrote: > 2016-09-21 8:54 GMT+02:00 Yasuo Ohgaki : >> >> Hi Stas, >> >> On Wed, Sep 21, 2016 at 11:26 AM, Stanislav Malyshev >> wrote: >> > >> >> I think we are better to limit

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

On Wed, Sep 21, 2016 at 9:46 PM, Nikita Popov wrote: > Here's a PR for the revert-to-7.0 + deprecate variant, in case we wish to > adopt it: https://github.com/php/php-src/pull/2137 > Pretty much the most sensible solution to all this, from my point of view. Avoiding

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

On Wed, Sep 21, 2016 at 8:47 PM, Nicolas Grekas wrote: > > > See https://github.com/php/php-src/pull/2136 > > > > On a technical note this is a potentially breaking change for C > > extensions. Since it is a currently a `zend_bool` its value is > > truthy/falsy; you are

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

On Wed, Sep 21, 2016 at 7:51 PM, Ryan Pallas wrote: > > > On Wed, Sep 21, 2016 at 12:44 PM, Jakub Zelenka wrote: > >> Hi, >> >> On Wed, Sep 21, 2016 at 7:07 PM, Levi Morrison wrote: >> >>> On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas >>>

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

On Wed, Sep 21, 2016 at 12:44 PM, Jakub Zelenka wrote: > Hi, > > On Wed, Sep 21, 2016 at 7:07 PM, Levi Morrison wrote: > >> On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas >> wrote: >> >> To handle this in code written around current

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

On Wed, Sep 21, 2016 at 12:44 PM, Jakub Zelenka wrote: > Hi, > > On Wed, Sep 21, 2016 at 7:07 PM, Levi Morrison wrote: >> >> On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas >> wrote: >> >> To handle this in code written around current

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

> > See https://github.com/php/php-src/pull/2136 > > On a technical note this is a potentially breaking change for C > extensions. Since it is a currently a `zend_bool` its value is > truthy/falsy; you are now applying specific meaning to values. > > Maybe someone else will have more insight into

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

Hi, On Wed, Sep 21, 2016 at 7:07 PM, Levi Morrison wrote: > On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas > wrote: > >> To handle this in code written around current __toString seems pretty > > simple > > > > Yes it is, but that's not what we're

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

On Wed, Sep 21, 2016 at 2:55 AM, Nicolas Grekas wrote: > Hello, > > our turn to be hit by this 7.1 BC break in Symfony: > `ReflectionType::__toString()` now adds a `?` in front of type hints where > `null` is allowed by their default values. > > But since `zend_bool` is

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

It's a point release, it's not really "up for decision" whether BC can be broken or not on functionality that is working as intended (unless I misunderstand the release process). Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Wed, Sep 21, 2016 at 8:07 PM, Levi

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

On Wed, Sep 21, 2016 at 12:07 PM, Levi Morrison wrote: > On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas > wrote: >>> To handle this in code written around current __toString seems pretty >> simple >> >> Yes it is, but that's not what we're talking

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas wrote: >> To handle this in code written around current __toString seems pretty > simple > > Yes it is, but that's not what we're talking about: > BC is about having perfectly fine code working in e.g. 7.0 be still working

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

> To handle this in code written around current __toString seems pretty simple Yes it is, but that's not what we're talking about: BC is about having perfectly fine code working in e.g. 7.0 be still working fine on 7.1 *without any change*. Right now, we have red test suites on php7.1rc2. This

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

On Wed, Sep 21, 2016 at 10:13 AM, Nicolas Grekas wrote: > > > > See https://github.com/php/php-src/pull/2136 > >> > > > > I don't like this. > > > > I understand, really. I do have to deal with BC on Symfony side also and > it's a really hard constraint. Yet, we stick

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

On Wed, Sep 21, 2016 at 10:34 AM, Nicolas Grekas wrote: > > >> I'm not so sure its a BC though. Technically nullable types don't exist >> in 7.0 and as such would be impossible to return said question mark. Its >> only adding support for a new feature, not changing how

[PHP-DEV] Re: Help with mysqlnd bug?

Hi Richard, On 21.09.2016 19:39, Fleshgrinder wrote: On 9/21/2016 8:42 AM, Andrey Hristov wrote: Hi Richard, On 20.09.2016 21:02, Fleshgrinder wrote: Hi Andrey! I am writing you because you are the last person with actual commits in the mysqlnd extension. I would like to ask if you could

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

> > I'm not so sure its a BC though. Technically nullable types don't exist in > 7.0 and as such would be impossible to return said question mark. Its only > adding support for a new feature, not changing how an existing feature > works IMO. If nullable types had been in 7.0 its highly probably,

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

On Wed, Sep 21, 2016 at 6:13 PM, Nicolas Grekas wrote: > > >> See https://github.com/php/php-src/pull/2136 >>> >> >> I don't like this. >> > > I understand, really. I do have to deal with BC on Symfony side also and > it's a really hard constraint. Yet, we stick to it

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

> > See https://github.com/php/php-src/pull/2136 >> > > I don't like this. > I understand, really. I do have to deal with BC on Symfony side also and it's a really hard constraint. Yet, we stick to it as much as possible, in order to not add pain to others. Sometime, we have to be pragmatic and

Re: [PHP-DEV] HashDoS

On Wed, Sep 21, 2016 at 4:49 PM, Glenn Eggleton wrote: > This might be a bit off topic > > Given that you can set POST_REQUEST_SIZE in a production PHP application, > how likely is it really that an app will encounter a HashDos attack? > > From what I gather this will

Re: [PHP-DEV] HashDoS

This might be a bit off topic Given that you can set POST_REQUEST_SIZE in a production PHP application, how likely is it really that an app will encounter a HashDos attack? >From what I gather this will require MBs to GBs of data in order to cause a DoS. >From the web side, I think there

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

How big of a deal will this be come 7.2? or 8.0? A few projects will break on 7.1 regardless of whether the question mark is prepended or not, as has already been discussed in previous threads. The key is as Nikita has pointed out that if we don't prepend it this method is basically useless and

Re: [PHP-DEV] HashDoS

On Wed, Sep 21, 2016 at 4:05 PM, Tom Worster wrote: > On 9/21/16 8:37 AM, Rowan Collins wrote: > >> On 21 September 2016 13:02:20 BST, Glenn Eggleton >> wrote: >> >>> What if we had some sort of configuration limit on collision length? >>> >> >> Previous

Re: [PHP-DEV] HashDoS

On 9/21/16 8:37 AM, Rowan Collins wrote: On 21 September 2016 13:02:20 BST, Glenn Eggleton wrote: What if we had some sort of configuration limit on collision length? Previous discussions have come to the conclusion that the difference between normal collision frequency

Re: [PHP-DEV] HashDoS

On Wed, Sep 21, 2016 at 3:22 PM, Niklas Keller wrote: > 2016-09-21 14:37 GMT+02:00 Rowan Collins : > > > On 21 September 2016 13:02:20 BST, Glenn Eggleton > > wrote: > > >What if we had some sort of configuration limit on collision

Re: [PHP-DEV] HashDoS

On 9/20/16 10:25 PM, Stanislav Malyshev wrote: Note that to avoid problems with opcache we can only randomize on initial boot (even then synchronizing among different processes sharing opcache may be challenging). That means that the process would be running for extended time (at least days, in

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

On Wed, Sep 21, 2016 at 3:14 PM, Nikita Popov wrote: > On Wed, Sep 21, 2016 at 10:55 AM, Nicolas Grekas > wrote: > >> Hello, >> >> our turn to be hit by this 7.1 BC break in Symfony: >> `ReflectionType::__toString()` now adds a `?` in front of type

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

That still means that code designed for 7.0 will break while reflecting 7.0 code (`= null` scenario) when run on 7.1, effectively preventing upgrade, Niklas. On 21 Sep 2016 15:27, "Niklas Keller" wrote: > 2016-09-21 15:14 GMT+02:00 Nikita Popov : > > > On

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

2016-09-21 15:14 GMT+02:00 Nikita Popov : > On Wed, Sep 21, 2016 at 10:55 AM, Nicolas Grekas > > wrote: > > > Hello, > > > > our turn to be hit by this 7.1 BC break in Symfony: > > `ReflectionType::__toString()` now adds a `?` in front of type

Re: [PHP-DEV] RFC: Strict comparisons

Am 21.09.16 um 14:49 schrieb Vesa Kaihlavirta: On Tue, 20 Sep 2016 at 02:20 Dan Ackroyd wrote: Hi Vesa, On 19 September 2016 at 14:04, Vesa Kaihlavirta wrote: My idea is to add a strict_comparisons declaration that you can add at the beginning

Re: [PHP-DEV] HashDoS

2016-09-21 14:37 GMT+02:00 Rowan Collins : > On 21 September 2016 13:02:20 BST, Glenn Eggleton > wrote: > >What if we had some sort of configuration limit on collision length? > > Previous discussions have come to the conclusion that the difference >

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

On Wed, Sep 21, 2016 at 10:55 AM, Nicolas Grekas wrote: > Hello, > > our turn to be hit by this 7.1 BC break in Symfony: > `ReflectionType::__toString()` now adds a `?` in front of type hints where > `null` is allowed by their default values. > > But since `zend_bool`

Re: [PHP-DEV] RFC: Strict comparisons

On Tue, 20 Sep 2016 at 02:20 Dan Ackroyd wrote: > Hi Vesa, > > On 19 September 2016 at 14:04, Vesa Kaihlavirta > wrote: > > > > My idea is to add a strict_comparisons declaration that you can add at > the > > beginning of a file in the same way as

Re: [PHP-DEV] HashDoS

On 21 September 2016 13:02:20 BST, Glenn Eggleton wrote: >What if we had some sort of configuration limit on collision length? Previous discussions have come to the conclusion that the difference between normal collision frequency and sufficient for a DoS is so large that

[PHP-DEV] UGLY Benchmark Results for PHP Master 2016-09-21

Results for project PHP master, build date 2016-09-21 06:25:36+03:00 commit: ea52b84 previous commit:dc59aaf revision date: 2016-09-20 12:18:55+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] HashDoS

Hello, What if we had some sort of configuration limit on collision length? Would give most of us a viable way to prevent our apps from being attacked, and yet in the use cases where we require a higher limit we retain the ability to up the limit or disable it completely. Regards, Glenn On Wed,

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

> Curious: Why do you depend on the string representation? __toString is the only public interface on ReflectionType that allows getting the type name, so people already build things on top. See http://php.net/ReflectionType

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

Hi, On Wed, 2016-09-21 at 10:55 +0200, Nicolas Grekas wrote: > our turn to be hit by this 7.1 BC break in Symfony: > `ReflectionType::__toString()` now adds a `?` in front of type hints where > `null` is allowed by their default values. Curious: Why do you depend on the string representation?

[PHP-DEV] Fix ReflectionType::__toString() BC break

Hello, our turn to be hit by this 7.1 BC break in Symfony: `ReflectionType::__toString()` now adds a `?` in front of type hints where `null` is allowed by their default values. But since `zend_bool` is really an `unsigned char`, we have plenty of room to store and forward this semantic subtlety

Re: [PHP-DEV] HashDoS

2016-09-21 8:54 GMT+02:00 Yasuo Ohgaki : > Hi Stas, > > On Wed, Sep 21, 2016 at 11:26 AM, Stanislav Malyshev > wrote: > > > >> I think we are better to limit max collisions. > >> I'm +1 for Nikita's proposal does this. > > > > Max collision per what? How

Re: [PHP-DEV] HashDoS

Hi Stas, On Wed, Sep 21, 2016 at 11:26 AM, Stanislav Malyshev 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