Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91820
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.51 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <6796160E-FAA7-42A3-953A-2D000F8BA294@heroku.com>
References: <CAEKnhAE1SJn46Lpefih_vWyjiT4UjP4DGj4BNZD9B-0TGSZgiQ@mail.gmail.com>
	<6796160E-FAA7-42A3-953A-2D000F8BA294@heroku.com>
Date: Mon, 21 Mar 2016 18:30:31 +0000
Message-ID: <CAEKnhAGukUL=vTQgKquUrV-E43w9gb6fZ6UxHKABa8nF0+O0_g@mail.gmail.com>
To: David Zuelke <dz@heroku.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1140f582ac6322052e934ab7
Subject: Re: [PHP-DEV] OpenSSL ext status including port to OpenSSL 1.1
From: bukka@php.net (Jakub Zelenka)

--001a1140f582ac6322052e934ab7
Content-Type: text/plain; charset=UTF-8

Hi David

On Sun, Mar 20, 2016 at 9:08 PM, David Zuelke <dz@heroku.com> wrote:

> On 20.03.2016, at 20:50, Jakub Zelenka <bukka@php.net> wrote:
> >
> > Hi,
> >
> > I just wanted to send a quick update about my recent work on openssl ext
> in
> > case someone else wanted to start something similar so we don't have a
> > wasted effort on that. :)
> >
> > 1. Error queueing
> >
> > I'm more or less done with a patch for error storing and clearing OpenSSL
> > error queue:
> >
> >
> https://github.com/php/php-src/compare/PHP-7.0...bukka:openssl_error_store
>
> Good stuff! Just FYI, there has been decent progress on the discussion
> around how to make libpq behave better with openssl errors (that's what I
> think prompted this change originally by way of a ticket); looks like
> that'll land in the next point release(s). But since other extensions' libs
> may also use openssl, the same issue can arise again anytime, so storing
> the errors ourselves on the PHP side is a great change that fixes all
> (well, most of) those potential issues in one sweep.
>
>
Nice to know that libpq got fixed as I think that the main issue (segfault)
was there. But as you say it will be useful to have a queueing for other
possible issues in the future.


>
> > I have been slowly working on a more complete test for
> openssl_error_string
> > that will cover most real error cases. There is still quite a lot of work
> > that I need to do but the incomplete test can be seen here:
> >
> >
> https://github.com/bukka/php-util/blob/master/tests/openssl/openssl_error_string_basic.phpt
> >
> > The idea is that I would like to create a PR against 7.0 after I'm happy
> > with that test so it can be tested by others and then merged. Then I plan
> > to merge the AEAD work that is complete but overlaps slightly with this
> one
> > so I want to merge it after that...
>
> Any plans to port that back to 5.6 as well? I'd really love to see that,
> considering how it fixes real issues in the wild, and how long the security
> fix phase for 5.6 will be.
>

I think that the changes are too big for 5.6. There are some additional
changes in it to get error codes from functions which would need further
checking as technically we still support 0.9.7 and 0.9.6 for 5.6 (some
functions return void on these versions). Also it would be quite a bit of
work to port it as the openssl.c is a bit different in 7.0. I think that
after libpq is fixed the motivation for that is much smaller and the fact
is that it's not really a bug in openssl ext. It's more improvement that
helps fix some possible issue and that's why I think that 7.0 is a perfect
version for it. And if someone has really an issue with that, they can
always clear the error queue with openssl_error_string...


>
> > 2. OpenSSL 1.1 port
> >
> > I have got a port of the extension to work on OpenSSL 1.1. There has been
> > quite a bit of changes mainly due to the fact that most structures are
> now
> > opaque (but also some other changes)
>
> I assume 1.0.whatever-is-in-ubuntu will remain usable? Or do we plan on
> requiring 1.1 in, say, 7.1?
>
>
So the plan is that 7.1 will support version 1.0.1, 1.0.2 and 1.1.0 . So no
requiring 1.1 - it will work for older versions as well. ;)

Cheers

Jakub

--001a1140f582ac6322052e934ab7--