[PHP-DEV] PHP 7.0.11 is available

[Anatol Belski]

Hi,

The PHP development team announces the immediate availability of PHP 7.0.11.
This is a security release. Several security bugs were fixed in this
release.

All PHP 7.0 users are encouraged to upgrade to this version.

For source downloads of PHP 7.0.11 please visit our downloads page:
http://www.php.net/downloads.php

Windows binaries can be found on http://windows.php.net/download/

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-7.php#7.0.11


Below is the verification information for the downloads:

php-7.0.11.tar.bz2
SHA256 hash:
f99b729dc1149858844b18af1e8c0de6dd1cdfdd52e22fbb4de2aa78bf9bf7f1
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJX2EveAAoJELyqMOqcDVdjn5MH/2KNK1thwKuHfJznf/Cjr2On
O04MBi0DD4vysV0wQsXO0gxrGdU0e5fjIEYpMRhsNSChc3x3kpeOVOo7sfK0+E6v
Kr+SW5ZzUWVwVJVDkJgwDoOyK3rIT5VcEywZw+SUYGDKjlNAnOLRKqoO76e3YmiR
FSKNj7A0J6YkQPJKk0cEFkS76zGuaEnHt0REtJr9T5sXIz6Ql5TKHavQKdU502cw
VfaY4NQ7QBc+dqQK4CFQKUaFXm/wQD4j4/boy0qnfD6lJSRpaMhPX9OavQh3/smc
7WXstgej4jQrO+l+j8/vC9cxJwu4zmtFdkDYQbXz+OZ2LqIOCrjOZ79cdKszo6M=
=sp6J
-END PGP SIGNATURE-


php-7.0.11.tar.gz
SHA256 hash:
02d27b5d140dbad8d400a95af808e1e9ce87aa8d2a2100870734ba26e6700d79
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJX2EviAAoJELyqMOqcDVdj2owH/1CLAsYKRi+Ux8JGlUJ5P3Yy
K+jMS5/pPDBsrBMX+ly9bKGMIx8cyEz5TBkjVRXyDZmvKLX5W2jQjZG1xkjV+kj/
bZhyXo/XWqbLmsRhmDsPVFjeH2GVAaeQkCFLYUVn1px3v/yjftSvYNi3TdmxrSsW
dWPMK/g0STa0OPKw6lVcpUy5KuV4PXxFGn03BeHnUk/MkKOULGDOpB9oN4cd0B6F
Z4uYFRqbs4VKO2GOsoXXx14ro6ocRuvZZ18fMvJyMIgxI9EQHyv1RrhZ/vqPWwUc
EgvJoIb1qrdqnDmpZ1T3tTuPpztn9zD3tWEa+neJAA2CDXFUSwl2rnP7mSb9Z48=
=/0YL
-END PGP SIGNATURE-


php-7.0.11.tar.xz
SHA256 hash:
d4cccea8da1d27c11b89386f8b8e95692ad3356610d571253d00ca67d524c735
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJX2EvlAAoJELyqMOqcDVdjSYoH/3nR7PnnVRnF/BgtsJTYwkai
a0cUVmlu77RFFdeZeZmnvWAIC+yd+GarJg2VKmV5QgbpR+DkExcZdFBktb7oDH+/
g4aJ1ve6HnzuP3pbkLtohCYakb4Wu2akVXxLDaBjNvvD1XL4GPOCLgGbNwM6RcKU
jkEsR4YxUJNht5utT749MyYhR5IHwWeUJO7zaTmvG/q6pvVLR8TNj0f6kuTaKhCa
Bj/8HZN5+tAtgTLfQpQzHchiS4kEZkUMNcKeSbKMRSHWkXEWKXE+ygszwP4BWOkr
OTU8nNfsV5OEiekj4+SmKQ8B6+Or6J6OhXtedeZrAez8LQ4iF6NrzCIpE8bMfos=
=Xxno
-END PGP SIGNATURE-


Regards,
Anatol Belski and Ferenc Kovacs


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] HashDoS

[Scott Arciszewski]

Would the Internals team be open to discussing mitigating HashDoS in a
future version of PHP? i.e. everywhere, even for json_decode() and friends,
by fixing the problem rather than capping the maximum number of input
parameters and hoping it's good enough.

I'd propose SipHash (and/or a derivative): https://www.131002.net/siphash/

(Look at all the other languages that already adopted SipHash.)

https://medium.freecodecamp.com/hash-table-attack-8e4371fc5261#.s5r5j42x3

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 

Re: [PHP-DEV] HashDoS

[Nikita Popov]

On Thu, Sep 15, 2016 at 8:48 PM, Scott Arciszewski 
wrote:

> Would the Internals team be open to discussing mitigating HashDoS in a
> future version of PHP? i.e. everywhere, even for json_decode() and friends,
> by fixing the problem rather than capping the maximum number of input
> parameters and hoping it's good enough.
>
> I'd propose SipHash (and/or a derivative): https://www.131002.net/siphash/
>
> (Look at all the other languages that already adopted SipHash.)
>
> https://medium.freecodecamp.com/hash-table-attack-8e4371fc5261#.s5r5j42x3
>

Previous discussion on the topic:
http://markmail.org/message/ttbgcvdu4f7uymfb

Nikita

Re: [PHP-DEV] RFC - Immutable classes

[Fleshgrinder]

On 9/14/2016 7:25 PM, Mathieu Rochette wrote:
> yeah the example is not that great, I'll usually want to clone to
> avoid calling a constructor with to many parameters (or a constructor
> doing too many things not needed here)
> 

That's exactly the reason why we want the _clone_ modifier. :)

On 9/14/2016 7:25 PM, Mathieu Rochette wrote:
> what's the difference between the two for an immutable class?
> 

The difference is that the engine cannot reason whether you need a clone
now or not. Allowing cloning in any context directly results in the fact
that someone from the outside can receive a copy of the object that is
actually mutable. However, exactly that is what we want to avoid by all
means.

It's true that userland deep cloning implementations will need to check
whether the instance at hand is cloneable or not. But as a matter of
fact they need to do that already anyways because there is no guarantee
that an object is actually cloneable because the `__clone` callback
could be invisible (`protected`/`private`) already.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] HashDoS

[Yasuo Ohgaki]

Hi Nikita,

On Fri, Sep 16, 2016 at 3:56 AM, Nikita Popov  wrote:
>
> Previous discussion on the topic:
> http://markmail.org/message/ttbgcvdu4f7uymfb

Your proposal is mandatory, IMHO.
Let's implement it ASAP.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] HashDoS

[Stanislav Malyshev]

Hi!

On 9/15/16 11:48 AM, Scott Arciszewski wrote:
> Would the Internals team be open to discussing mitigating HashDoS in a
> future version of PHP? i.e. everywhere, even for json_decode() and friends,
> by fixing the problem rather than capping the maximum number of input
> parameters and hoping it's good enough.
> 
> I'd propose SipHash (and/or a derivative): https://www.131002.net/siphash/

I am worries about performance. Base hash structure has to be *very*
fast. I have doubts that cryptographic function can perform at these
levels. Did you test what is performance of this function compared to
existing hash function?

> 
> (Look at all the other languages that already adopted SipHash.)

Adopted as base data structure in the engine? Which ones? What were the
performance costs?
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-09-16

[lp_benchmark_robot]

Results for project PHP master, build date 2016-09-15 06:24:43+03:00
commit: 902e9ad
previous commit:494c5dc
revision date:  2016-09-15 03:07:31+03:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.17% -0.49%  0.34%  
  7.01%
:-|   Drupal 7.36 cgi -T1  0.16% -0.22% -1.22%  
  4.92%
:-|   MediaWiki 1.23.9 cgi -T5000  0.14%  0.00%  0.25%  
  3.72%
:-(   bench.php cgi -T100  1.90% -1.49% 31.83%  
 -4.24%
:-|  micro_bench.php cgi -T10  0.01%  0.60% 14.06%  
  2.89%
:-(  mandelbrot.php cgi -T100  0.03% -2.52% 30.65%  
 -4.72%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/bad-benchmark-results-for-php-master-2016-09-15/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] HashDoS

[Thomas Hruska]

On 9/15/2016 5:20 PM, Stanislav Malyshev wrote:

Hi!

On 9/15/16 11:48 AM, Scott Arciszewski wrote:

Would the Internals team be open to discussing mitigating HashDoS in a
future version of PHP? i.e. everywhere, even for json_decode() and friends,
by fixing the problem rather than capping the maximum number of input
parameters and hoping it's good enough.

I'd propose SipHash (and/or a derivative): https://www.131002.net/siphash/


I am worries about performance. Base hash structure has to be *very*
fast. I have doubts that cryptographic function can perform at these
levels. Did you test what is performance of this function compared to
existing hash function?


If anyone wants a VERY rough estimate of relative performance 
degradation as a result of switching to SipHash, here's a somewhat naive 
C++ implementation of a similar data structure to that found in PHP:


https://github.com/cubiclesoft/cross-platform-cpp

(See the "Hash performance benchmark" results at the above link.)

In short, there's a significant degradation just switching from djb2 to 
SipHash depending on key type.  A similar effect would probably be seen 
in PHP.


Randomizing the starting hash value for djb2 during the core startup 
sequence *could* also be effective for mitigating HashDoS.  Extensive 
testing would have to be done to determine how collision performance 
plays out with randomized starting hash values.  I can't find any 
arguments anywhere against using randomized starting hash values for 
djb2.  Also of note, the 33 multiplier seems more critical than anything 
else for mixing bits together.


--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php