Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » PHP 7.0 and openssl 1.1 »

PHP 7.0 and openssl 1.1

php.internals

Rasmus Lerdorf

9 years ago
Jakub, what do you think about back-porting the openssl-1.1 supporting changes to the PHP-7.0 branch? I think it is too early to have PHP-7.0 not compile on new Linux versions and right now it doesn't compile on any Linux that has openssl-1.1. -Rasmus

Jakub Zelenka

9 years ago
Hi Rasmus, On Sun, Jan 22, 2017 at 1:28 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> Jakub, what do you think about back-porting the openssl-1.1 supporting > changes to the PHP-7.0 branch? I think it is too early to have PHP-7.0 not > compile on new Linux versions and right now it doesn't compile on any Linux > that has openssl-1.1. > >
The thing is that the patch required quite a lot of changes and it was based on the AEAD and OpenSSL error storing changes so the it changed quite a lot of code. So all changes together makes some difference between 7.0 and 7.1: [jakub@localhost 71]$ git diff --stat PHP-7.0 ext/openssl/*.[c,h] ext/openssl/openssl.c | 1991 ... ext/openssl/php_openssl.h | 25 ... ext/openssl/xp_ssl.c | 199 ... 3 files changed, 1613 insertions(+), 602 deletions(-) This shows just openssl ext source files but there are some other changes for phar and some tweaks in tests. For that reason I decided that it will be better to target just 7.1 to have full QA cycle which was a good decision because I needed to fix few things in beta and rc. It means that the back-port would require some work to extract just the porting bits and all test it. It might be slightly trickier as 7.0 still support 0.9.8 which might complicate things a bit. Also there is still one failing SNI tests that needs some looking and couple of things needs a look as well so the port is still not 100% complete. In general I'm not so sure if it's really worth it to invest too much time into back-porting it as I'm not sure how many users would really appreciate it (meaning how many users are not able to update to PHP 7.1 and need to use OpenSSL 1.1.). It might be also quite a big patch for the point release but if RM is ok with that and someone wants to spend that time on porting it, I can do the review. Personally I have got some other stuff on my list (including finishing the port in 7.1 and some other OpenSSL fixes) so won't probably have time for anything else than review. Cheers Jakub

Rasmus Lerdorf

9 years ago
Ok, I thought perhaps the changes for just openssl-1.1 api compatibility would be easier to separate out, but I guess not. I did have a look at it and you are right, while some of the changes are trivial, others are more involved. Fedora 26, and I would guess any Linux distro release that comes out this year, will ship with openssl-1.1 so they will not be able to run any version of PHP prior to 7.1. -Rasmus On Sun, Jan 22, 2017 at 11:33 AM, Jakub Zelenka <bukka@php.net> wrote:

Alice Wonder

9 years ago
If someone on such a distro really can't use PHP 7.1.x, LibreSSL can be installed in parallel to OpenSSL (I do on CentOS) and I suspect php 7.0 will build against it (5.6.x does and 7.1.x does) Also, I suspect older OpenSSL shared libraries could probably be installed in parallel. So it can be done if really needed. On 01/22/2017 07:24 PM, Rasmus Lerdorf wrote:

Rasmus Lerdorf

9 years ago
On Mon, Jan 23, 2017 at 12:31 AM, Alice Wonder <alice@librelamp.com> wrote:
> If someone on such a distro really can't use PHP 7.1.x, LibreSSL can be > installed in parallel to OpenSSL (I do on CentOS) and I suspect php 7.0 > will build against it (5.6.x does and 7.1.x does) > > Also, I suspect older OpenSSL shared libraries could probably be installed > in parallel. > > So it can be done if really needed.
Yes, of course it can be done with a bit (or a lot depending on the distro) fiddling. And it is also rather tricky to build against libressl or a different version of openssl because we have things like libcurl, libpq, libc-client and probably a few others as well that are linked against the system openssl library. You will need to built alternative versions of those too. And for libressl, even if you get it built, you are going to see quite a few test failures. This is the current state of make test TESTS=ext/openssl when PHP-7.0 is built against the latest version of libressl: Number of tests : 105 98 Tests skipped : 7 ( 6.7%) -------- Tests warned : 0 ( 0.0%) ( 0.0%) Tests failed : 32 ( 30.5%) ( 32.7%) Expected fail : 0 ( 0.0%) ( 0.0%) Tests passed : 66 ( 62.9%) ( 67.3%) --------------------------------------------------------------------- Time taken : 446 seconds ===================================================================== ===================================================================== FAILED TEST SUMMARY --------------------------------------------------------------------- #46127, openssl_sign/verify: accept different algos [ext/openssl/tests/bug46127.phpt] Bug #48182: ssl handshake fails during asynchronous socket connection [ext/openssl/tests/bug48182.phpt] Bug #54992: Stream not closed and error not returned when SSL CN_match fails [ext/openssl/tests/bug54992.phpt] Bug #65538: SSL context "cafile" supports stream wrappers [ext/openssl/tests/bug65538_001.phpt] Bug #65538: SSL context "cafile" disallows URL stream wrappers [ext/openssl/tests/bug65538_002.phpt] Bug #65538: SSL context "cafile" supports phar wrapper [ext/openssl/tests/bug65538_003.phpt] Bug #65729: CN_match gives false positive when wildcard is used [ext/openssl/tests/bug65729.phpt] Bug #68265: SAN match fails with trailing DNS dot [ext/openssl/tests/bug68265.phpt] Bug #68879: Match IP address fields in subjectAltName checks [ext/openssl/tests/bug68879.phpt] Bug #68920: peer_fingerprint input checks should be strict [ext/openssl/tests/bug68920.phpt] Bug #69215: Crypto servers should send client CA list [ext/openssl/tests/bug69215.phpt] Bug #72165 Null pointer dereference - openssl_csr_new [ext/openssl/tests/bug72165.phpt] Bug #73072: Invalid path SNI_server_certs causes segfault [ext/openssl/tests/bug73072.phpt] capture_peer_cert context captures on verify failure [ext/openssl/tests/capture_peer_cert_001.phpt] openssl_error_string() tests [ext/openssl/tests/openssl_error_string_basic.phpt] Testing peer fingerprint on connection [ext/openssl/tests/openssl_peer_fingerprint_basic.phpt] Peer verification enabled for client streams [ext/openssl/tests/peer_verification.phpt] Peer verification matches SAN names [ext/openssl/tests/san_peer_matching.phpt] Capture SSL session meta array in stream context [ext/openssl/tests/session_meta_capture.phpt] sni_server [ext/openssl/tests/sni_server.phpt] Basic bitwise stream crypto context flag assignment [ext/openssl/tests/stream_crypto_flags_001.phpt] TLSv1.1 and TLSv1.2 bitwise stream crypto flag assignment [ext/openssl/tests/stream_crypto_flags_002.phpt] Server bitwise stream crypto flag assignment [ext/openssl/tests/stream_crypto_flags_003.phpt] Specific protocol method specification [ext/openssl/tests/stream_crypto_flags_004.phpt] TLS server rate-limits client-initiated renegotiation [ext/openssl/tests/stream_server_reneg_limit.phpt] Verify host name by default in client transfers [ext/openssl/tests/stream_verify_peer_name_001.phpt] Allow host name mismatch when "verify_host" disabled [ext/openssl/tests/stream_verify_peer_name_002.phpt] Host name mismatch triggers error [ext/openssl/tests/stream_verify_peer_name_003.phpt] Specific crypto method for ssl:// transports. [ext/openssl/tests/streams_crypto_method.phpt] tlsv1.0 stream wrapper [ext/openssl/tests/tlsv1.0_wrapper.phpt] tlsv1.1 stream wrapper [ext/openssl/tests/tlsv1.1_wrapper.phpt] tlsv1.2 stream wrapper [ext/openssl/tests/tlsv1.2_wrapper.phpt] ===================================================================== -Rasmus

Alice Wonder

9 years ago
Actually I found that wasn't the case. To build php against an alternat openssl API - I did have to rebuild net-snmp but curl, for example, at least on CentOS uses NSS for it's TLS and so didn't need to be rebuild to build PHP against a different OpenSSL API. Building in mock, the only php dependency that had an OpenSSL API dependency was net-snmp. And if I kept the same API for net-snmp, I didn't have to replace the system net-snmp for php to work properly - only the net-snmp used in mock. That was php 5.6.x and 7.1.x though, 7.0.x may have different results, but I doubt it. On 01/23/2017 02:05 AM, Rasmus Lerdorf wrote:

Rasmus Lerdorf

9 years ago
On Mon, Jan 23, 2017 at 12:52 PM, Alice Wonder <alice@librelamp.com> wrote:
> Actually I found that wasn't the case. To build php against an alternat > openssl API - I did have to rebuild net-snmp but curl, for example, at > least on CentOS uses NSS for it's TLS and so didn't need to be rebuild to > build PHP against a different OpenSSL API. > > Building in mock, the only php dependency that had an OpenSSL API > dependency was net-snmp. And if I kept the same API for net-snmp, I didn't > have to replace the system net-snmp for php to work properly - only the > net-snmp used in mock. > >
Well, you got lucky with your libcurl then. On Debian the default is openssl. You can optionally choose either gnutls or nss instead if you like. I am pretty sure Centos also has a libcurl-openssl variant that people might be using: libcurl3 - easy-to-use client-side URL transfer library (OpenSSL flavour) libcurl3-gnutls - easy-to-use client-side URL transfer library (GnuTLS flavour) libcurl3-nss - easy-to-use client-side URL transfer library (NSS flavour) libcurl having those alternatives is probably the easiest dependency. libpq (PostgreSQL) and libc-client do not, as far as I know. -Rasmus

Remi Collet

9 years ago
Le 23/01/2017 à 04:24, Rasmus Lerdorf a écrit :
> Ok, I thought perhaps the changes for just openssl-1.1 api compatibility > would be easier to separate out, but I guess not. I did have a look at it > and you are right, while some of the changes are trivial, others are more > involved. Fedora 26, and I would guess any Linux distro release that comes > out this year, will ship with openssl-1.1 so they will not be able to run > any version of PHP prior to 7.1.
Fedora 26 will have openssl 1.1 and PHP 7.1. BTW, still a good idea to be able to build previous versions. Fedora also have a compat-openssl10 (version 1.0.2j for now) which allow to build not-compatible applications. But as said by Rasmus, there is tons of extensions and libraries linked against openssl, and having both versions loaded in the same process can only be a huge mess, and raise terrible issues. IIRC, debian even have a patch for this. https://anonscm.debian.org/git/pkg-php/php.git/tree/debian/patches/0048-Merge-OpenSSL-1.1.0-support-from-PHP-7.1-branch.patch Remi

Jakub Zelenka

9 years ago
On Mon, Jan 23, 2017 at 10:48 AM, Remi Collet <remi@fedoraproject.org> wrote:
> Le 23/01/2017 à 04:24, Rasmus Lerdorf a écrit : > > Ok, I thought perhaps the changes for just openssl-1.1 api compatibility > > would be easier to separate out, but I guess not. I did have a look at it > > and you are right, while some of the changes are trivial, others are more > > involved. Fedora 26, and I would guess any Linux distro release that > comes > > out this year, will ship with openssl-1.1 so they will not be able to run > > any version of PHP prior to 7.1. > > Fedora 26 will have openssl 1.1 and PHP 7.1. > > BTW, still a good idea to be able to build previous versions. > > Fedora also have a compat-openssl10 (version 1.0.2j for now) which allow > to build not-compatible applications. > > But as said by Rasmus, there is tons of extensions and libraries linked > against openssl, and having both versions loaded in the same process can > only be a huge mess, and raise terrible issues. > > IIRC, debian even have a patch for this. > https://anonscm.debian.org/git/pkg-php/php.git/tree/ > debian/patches/0048-Merge-OpenSSL-1.1.0-support-from-PHP-7.1-branch.patch > >
Well this is just 7.1 opensssl ext which includes things that we should never add to the bug fixing release (like dropping support for 0.9.8, AEAD, pkey changes and other stuff). Not really an acceptable patch though...

Remi Collet

9 years ago
>> But as said by Rasmus, there is tons of extensions and libraries linked >> against openssl, and having both versions loaded in the same process can >> only be a huge mess, and raise terrible issues.
Here is a minimal patch which seems ok (test suite passes) https://github.com/remicollet/remirepo/blob/master/scl-php70/php/php-7.0.17-openssl11.patch If it may helps some other dev, which need to build 7.0 on a recent distro... @Jakub, your eyes welcome on it. 2 minor changes on tests (001.php and openssl_free_key.phpt) thant I plan to apply on 7.1 (rely on local openssl.cnf instead of system one) Remi;

Jakub Zelenka

9 years ago
Hi, On Sun, Mar 12, 2017 at 1:49 PM, Remi Collet <remi@fedoraproject.org> wrote:
> >> But as said by Rasmus, there is tons of extensions and libraries linked > >> against openssl, and having both versions loaded in the same process can > >> only be a huge mess, and raise terrible issues. > > Here is a minimal patch which seems ok (test suite passes) > > https://github.com/remicollet/remirepo/blob/master/scl- > php70/php/php-7.0.17-openssl11.patch > > If it may helps some other dev, which need to build 7.0 on a recent > distro... > > @Jakub, your eyes welcome on it. > >
Had a very quick look and it seems to be missing compat part for 1.0.2- (e.g. DH_get0_key and other getters / setters that are not in there) so it won't probably work anywhere else than 1.1. In any case it looks like a good start. Will try to take a look a bit more later. Btw. I remember that there are few more changes required in phar ext that uses MD.
> 2 minor changes on tests (001.php and openssl_free_key.phpt) thant I > plan to apply on 7.1 (rely on local openssl.cnf instead of system one) >
Sounds good! Cheers Jakub

Jakub Zelenka

9 years ago
Hi, On Sun, Mar 12, 2017 at 10:28 PM, Jakub Zelenka <bukka@php.net> wrote:
> Hi, > > On Sun, Mar 12, 2017 at 1:49 PM, Remi Collet <remi@fedoraproject.org> > wrote: > >> >> But as said by Rasmus, there is tons of extensions and libraries linked >> >> against openssl, and having both versions loaded in the same process >> can >> >> only be a huge mess, and raise terrible issues. >> >> Here is a minimal patch which seems ok (test suite passes) >> >> https://github.com/remicollet/remirepo/blob/master/scl-php70 >> /php/php-7.0.17-openssl11.patch >> >> If it may helps some other dev, which need to build 7.0 on a recent >> distro... >> >>
After thinking about it and considering that distros patching the 7.0 openssl ext just for the OpenSSL 1.1 support, I started working on the complete patch for 7.0 only. I wanted to initially start with the above one but after I get it from Remi's history (the link above doesn't work), I noticed that there are lots of missing bits and it doesn't even apply. So I started from scratch - backported the related stuff from 7.1 and port old openssl_(en|de)crypt. It's only in openssl.c for now. I haven't tested it yet with OpenSSL 1.1 (which I will doing later) but it works with 1.0.2. It's still a WIP but wanted to give you an update so you know that the work is in progress. You can see all changes in here: https://github.com/php/php-src/compare/PHP-7.0...bukka:openssl_1_1_for_7_0 Cheers Jakub

Remi Collet

9 years ago
Le 24/03/2017 à 20:31, Jakub Zelenka a écrit :
> After thinking about it and considering that distros patching the 7.0 > openssl ext just for the OpenSSL 1.1 support, I started working on the > complete patch for 7.0 only. I wanted to initially start with the above one > but after I get it from Remi's history (the link above doesn't work), I > noticed that there are lots of missing bits and it doesn't even apply.
:( Sad lost of energy... BTW, my patch is saved in 2 places https://git.remirepo.net/cgit/rpms/scl-php70/php.git/tree/php-7.0.17-openssl11.patch https://github.com/remicollet/php-src/tree/PHP-7.0-openssl11 and even (if someone interested) https://github.com/remicollet/php-src/tree/PHP-5.6-openssl11 BTW, indeed, compatibility bits are missing. I will try to give your a try Remi.

Anatol Belski

9 years ago
Hi,
> -----Original Message----- > From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com] > Sent: Monday, January 23, 2017 4:25 AM > To: Jakub Zelenka <bukka@php.net> > Cc: PHP internals <internals@lists.php.net> > Subject: [PHP-DEV] Re: PHP 7.0 and openssl 1.1 > > Ok, I thought perhaps the changes for just openssl-1.1 api compatibility would > be easier to separate out, but I guess not. I did have a look at it and you are right, > while some of the changes are trivial, others are more involved. Fedora 26, and I > would guess any Linux distro release that comes out this year, will ship with > openssl-1.1 so they will not be able to run any version of PHP prior to 7.1. > > -Rasmus
Were it maybe an idea, to provide the ext/openssl from 7.1 as a separate package? It is likely to be much easier to adapt for 7.0, so at least 7.0 could be supported. Probably not without a quirk, too, as some other extensions might be indirectly affected, non core as well. Otherwise, regarding OpenSSL 1.1.0 itself - it's not an LTS release and it's uncertain what comes next. In turn - 1.0.2 is LTS and is supported for at least next 3 years, but no 1.0.3 is planned https://www.openssl.org/policies/releasestrat.html . From this, it appears a bit hard to plan long term in PHP currently, as depending on the further OpenSSL development we might have to sync 7.1 again after 1.1.0 is EOL, but 1.0.2 should be sufficient for all the life time of PHP 7.1. Regards Anatol