Re: h2 broken in 2.4.36 with OpenSSL 1.1.1? Related to SSL_MODE_AUTO_RETRY?

Adjusted SSL_read() rc value 0 handling applied in r1843954 to trunk. I'll let it sit there until tomorrow for comments and then suggest for backport. Am 15.10.2018 um 12:55 schrieb Rainer Jung: Am 15.10.2018 um 10:02 schrieb Stefan Eissing: Am 14.10.2018 um 00:46 schrieb Rainer Jung :

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

On 10/15/2018 01:25 PM, William A Rowe Jr wrote: On Sun, Oct 14, 2018 at 4:38 PM Dennis Clarke > wrote: As a red herring that illustrates how oddball the situation could get : $ /usr/sfw/bin/openssl version 2>&1 | cut -f1 -d\( OpenSSL 0.9.7d 17 Mar

Re: [Discussion] Limit the scope of 2.4.x patches until 2.4.next is released?

On 10/15/2018 7:10 AM, William A Rowe Jr wrote: Like my beg for getting us to the 2.4.35 release tag, I'd like to propose we keep patches to branches/2.4.x/ generally within the scope of straightening out the remaining quirks related to the OpenSSL 1.1.1 API and library behavior changes (and

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

On Sun, Oct 14, 2018 at 4:38 PM Dennis Clarke wrote: > > As a red herring that illustrates how oddball the situation could get : > > $ /usr/sfw/bin/openssl version 2>&1 | cut -f1 -d\( > OpenSSL 0.9.7d 17 Mar 2004 > [...] > Segmentation Fault(coredump) > I think we can safely ignore OpenSSL

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

On Wed, Oct 10, 2018 at 12:27 PM wrote: > Author: jim > Date: Wed Oct 10 17:27:33 2018 > New Revision: 1843478 > > @@ -21,7 +21,7 @@ Apache::TestRequest::module('ssl_ocsp'); > # support in earlier versions without messing around with stderr > my $openssl = Apache::TestSSLCA::openssl(); > if

Re: svn commit: r1843917 - /httpd/test/framework/trunk/t/ssl/ocsp.t

I see 'ocsp' in both lists, and 2>&1 redirects stderr to stdout unambiguously, resulting in correct evaluation of the `openssl list 2>&1` ~! /ocsp/ match. I will proceed with your veto to remove my " 2>&1" addition, restoring the original test by jorton, if you would like, and leave this file to

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

On Mon, Oct 15, 2018 at 10:10 AM Jim Jagielski wrote: > -1 (veto). > Correct. Your three commits against jorton's implementation are vetoed. They were incorrect. > 'list' is not a valid command. > You are wrong. The list-standard-commands feature was dropped from OpenSSL 1.1.0 and onwards.

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

Forget this. My patch works and is correct and handles the specific situation which is noted in the test case itself related to older versions. It is an IMPROVEMENT over what we currently have. The sole reason why Bill doesn't like it is because *I* committed it. Whatever. I have no desire or

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

-1 (veto). 'list' is not a valid command. > On Oct 15, 2018, at 11:04 AM, William A Rowe Jr wrote: > > On Mon, Oct 15, 2018 at 7:52 AM Jim Jagielski > wrote: > > And lest we forget, the orig version used: > > $openssl list -commands > > I have no idea what

Re: svn commit: r1843917 - /httpd/test/framework/trunk/t/ssl/ocsp.t

-1 (veto) Please revert. 'list' is NOT a command and this causes OCSP to be skipped. % openssl version OpenSSL 1.0.2p 14 Aug 2018 % openssl list -commands openssl:Error: 'list' is an invalid command. Standard commands asn1parse caciphers cms crl

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

On Mon, Oct 15, 2018 at 7:52 AM Jim Jagielski wrote: > > And lest we forget, the orig version used: > > $openssl list -commands > > I have no idea what version of openssl supports 'list'. The result > of which was that the ocsp testing was ALWAYS SKIPPED. > No, it wasn't skipped. We weren't

Re: [VOTE] Release httpd-2.4.36

> On Oct 15, 2018, at 10:20 AM, Stefan Eissing > wrote: > > > >> Am 15.10.2018 um 16:11 schrieb Jim Jagielski : >> >> It's up to the RM on whether or not to release... one can't veto a release >> and a -1 is not a veto. > > Huh? I was referring to "TLS 1.3 support isn't quite yet tested

Re: [VOTE] Release httpd-2.4.36

Hi, all; As a result of testing and further analysis of this release, I am calling this release dead on the vine and shall not pursue publishing it. We have -1 votes based on the recently discovered OpenSSL 1.1.1 behavior change [1]. Although this tag shall not become a release, I'd like to

Re: [VOTE] Release httpd-2.4.36

On 10/15/2018 04:20 PM, Stefan Eissing wrote: Am 15.10.2018 um 16:11 schrieb Jim Jagielski : It's up to the RM on whether or not to release... one can't veto a release and a -1 is not a veto. Huh? I was referring to "TLS 1.3 support isn't quite yet tested enough to warrant a public

Re: [VOTE] Release httpd-2.4.36

> Am 15.10.2018 um 16:11 schrieb Jim Jagielski : > > It's up to the RM on whether or not to release... one can't veto a release > and a -1 is not a veto. Huh? I was referring to "TLS 1.3 support isn't quite yet tested enough to warrant a public release". I wanted to point out that without

Re: [VOTE] Release httpd-2.4.36

It's up to the RM on whether or not to release... one can't veto a release and a -1 is not a veto. > On Oct 15, 2018, at 10:07 AM, Stefan Eissing > wrote: > > > >> Am 15.10.2018 um 15:58 schrieb Jim Jagielski : >> >> Considering all this, I am changing my vote from a +1 to a -1. I was not

[Discussion] Limit the scope of 2.4.x patches until 2.4.next is released?

Like my beg for getting us to the 2.4.35 release tag, I'd like to propose we keep patches to branches/2.4.x/ generally within the scope of straightening out the remaining quirks related to the OpenSSL 1.1.1 API and library behavior changes (and similar corrections for any alternate library

Re: [VOTE] Release httpd-2.4.36

> Am 15.10.2018 um 15:58 schrieb Jim Jagielski : > > Considering all this, I am changing my vote from a +1 to a -1. I was not able > to trigger this error, but this shows, at least IMO, that TLS 1.3 support > isn't quite yet tested enough to warrant a public release, unless we are > super

Re: [VOTE] Release httpd-2.4.36

Considering all this, I am changing my vote from a +1 to a -1. I was not able to trigger this error, but this shows, at least IMO, that TLS 1.3 support isn't quite yet tested enough to warrant a public release, unless we are super clear that it is "experimental" or "early access"... > On Oct

Re: [VOTE] Release httpd-2.4.36

> Am 15.10.2018 um 15:51 schrieb William A Rowe Jr : > > > > On Mon, Oct 15, 2018 at 3:06 AM Stefan Eissing > wrote: > > See my mail on the other thread. It seems that h2 traffic triggers a call > sequence that exposes a change in OpenSSL behaviour of SSL_read() between > 1.1.0 and

Re: [VOTE] Release httpd-2.4.36

On Mon, Oct 15, 2018 at 3:06 AM Stefan Eissing wrote: > > See my mail on the other thread. It seems that h2 traffic triggers a call > sequence that exposes a change in OpenSSL behaviour of SSL_read() between > 1.1.0 and 1.1.1. It looks as if mod_ssl interpreted the return codes of > SSL_read()

Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t

> On Oct 14, 2018, at 3:59 PM, William A Rowe Jr wrote: > > $ openssl xyz >/dev/null > Invalid command 'xyz'; type "help" for a list. > $ echo $? > 1 > $ openssl version > OpenSSL 1.1.0i-fips 14 Aug 2018 > > I have no idea which bastardization of the openssl command line tool you are >

mod_headers best practices and headers duplicated in the response

Hi everybody, apologies if this subject has been brought up in the past but I didn't find much. I have been working on some bugs like https://bz.apache.org/bugzilla/show_bug.cgi?id=62380 in which users report responses with the same header duplicated. To keep the story short, it seems that

Re: h2 broken in 2.4.36 with OpenSSL 1.1.1? Related to SSL_MODE_AUTO_RETRY?

Am 15.10.2018 um 10:02 schrieb Stefan Eissing: Am 14.10.2018 um 00:46 schrieb Rainer Jung : It seems the h2 failure only happens when building httpd against OpenSSL 1.1.1 (independent of TLS version used). I did a quick check with an httpd build against 1.1.0i and there the same vhost of

Re: [VOTE] Release httpd-2.4.36

> Am 14.10.2018 um 23:46 schrieb Daniel Ruggeri : > > Hi, Helmut; > Note that the vote may run longer than 72 hours as 72 is the minimum. As it > stands now, we have more than 3 binding +1 votes, but I am waiting for > closure on the conversation on-list about the tests with reported H2/TLS

Re: h2 broken in 2.4.36 with OpenSSL 1.1.1? Related to SSL_MODE_AUTO_RETRY?

> Am 14.10.2018 um 00:46 schrieb Rainer Jung : > > It seems the h2 failure only happens when building httpd against OpenSSL > 1.1.1 (independent of TLS version used). I did a quick check with an httpd > build against 1.1.0i and there the same vhost of the test framework instance > worked