Re: Failing http2.t in 2.4.36 [Was: NOTICE: Intent to T 2.4.36]

[Rainer Jung]

Hi Stefan,

it is the "input gone" (APR_EOF) case which went unnoticed by me. 
Although I patch the test suite to run with trace8 log level, http2 was 
set to debug in the test suite config and the "input gone" message is a 
trace message. See below for more details. The question is still whether 
this should have been handled non-fatally. Currently curl fails to do h2 
with httpd 2.4.36 as set up by the test suite.


Am 13.10.2018 um 18:53 schrieb Stefan Eissing:

Hi Rainer,

according to the log, the h2 code must be in the H2_SESSION_ST_BUSY state and 
the only cause I see is the same as you, namely an unexpected status from 
h2_session_read(), which should come via

 status = ap_get_brigade(c->input_filters,
 session->bbtmp, AP_MODE_READBYTES,
 block? APR_BLOCK_READ : APR_NONBLOCK_READ,
 H2MAX(APR_BUCKET_BUFF_SIZE, readlen));

block is 0 here and readlen should be (unless reconfigured via 
H2StreamMaxMemSize) 32kb.

Maybe you could just add a log line there to see what ap_get_brigade() returned 
there?

Strange.


I hope most of the added http2:debug log lines with logno AH* are 
self-explaining:


...

22:25:25.934782 [core:trace8] core_filters.c(554): [client 
127.0.0.1:36318] flushing now


22:25:25.934810 [core:trace8] core_filters.c(569): [client 
127.0.0.1:36318] total bytes written: 3197


22:25:25.934816 [core:trace8] core_filters.c(580): [client 
127.0.0.1:36318] brigade contains: bytes: 0, non-file bytes: 0, eor 
buckets: 0, morphing buckets: 0


22:25:25.934823 [http2:debug] h2_session.c(1552): [client 
127.0.0.1:36318] AH7: h2_session(75,BUSY,1): Into session_read 
non-blocking readlen 65536 read_start 103


22:25:25.934828 [http2:trace1] h2_filter.c(145): [client 
127.0.0.1:36318] h2_session(75): read, NONBLOCK_READ, mode=0, 
readbytes=65536


22:25:25.934878 [ssl:trace4] ssl_engine_io.c(2213): [client 
127.0.0.1:36318] OpenSSL: read 0/5 bytes from BIO#7ff098002b10 [mem: 
7ff0980164d3] (BIO dump follows)


22:25:25.934894 [ssl:trace7] ssl_engine_io.c(2136): [client 
127.0.0.1:36318] 
+-+


22:25:25.934898 [ssl:trace7] ssl_engine_io.c(2180): [client 
127.0.0.1:36318] 
+-+


22:25:25.934903 [http2:trace1] h2_filter.c(190): (70014)End of file 
found: [client 127.0.0.1:36318] h2_session(75): read


22:25:25.934908 [http2:debug] h2_session.c(1563): (70014)End of file 
found: [client 127.0.0.1:36318] AH0: h2_session(75,BUSY,1): 
session_read non-blocking readlen 65536 ap_get_brigade returned status 70014


22:25:25.934913 [http2:debug] h2_session.c(1603): (70014)End of file 
found: [client 127.0.0.1:36318] AH8: h2_session(75,BUSY,1): input gone


22:25:25.934917 [http2:trace1] h2_session.c(1605): (70014)End of file 
found: [client 127.0.0.1:36318] h2_session(75,BUSY,1): input gone


22:25:25.934921 [http2:debug] h2_session.c(1616): [client 
127.0.0.1:36318] AH4: h2_session(75,BUSY,1): session_read 
non-blocking readlen 65536 status 70014 (default case) 
session->io.bytes_read == read_start (103 == 103) returning status 70014


22:25:25.934926 [http2:debug] h2_session.c(1645): (70014)End of file 
found: [client 127.0.0.1:36318] AH9: h2_session(75,BUSY,1): 
h2_session_read non-blocking returning 70014


22:25:25.934931 [http2:debug] h2_session.c(1794): [client 
127.0.0.1:36318] AH03401: h2_session(75,BUSY,1): conn error -> shutdown


22:25:25.934938 [http2:debug] h2_session.c(589): [client 
127.0.0.1:36318] AH03068: h2_session(75,BUSY,1): sent 
FRAME[GOAWAY[error=0, reason='', last_stream=1]], frames=3/4 (r/s)



I reduced my long list of loaded modules to check, whether a filter in 
some module interacts badly, but the problem still happens with the 
following modules loaded:


mod_mpm_event.so
mod_authn_file.so
mod_authn_anon.so
mod_authn_socache.so
mod_authn_core.so
mod_authz_host.so
mod_authz_groupfile.so
mod_authz_user.so
mod_authz_owner.so
mod_authz_core.so
mod_access_compat.so
mod_auth_basic.so
mod_allowmethods.so
mod_socache_shmcb.so
mod_watchdog.so
mod_macro.so
mod_reqtimeout.so
mod_filter.so
mod_mime.so
mod_log_debug.so
mod_env.so
mod_headers.so
mod_unique_id.so
mod_setenvif.so
mod_version.so
mod_remoteip.so
mod_slotmem_shm.so
mod_slotmem_plain.so
mod_ssl.so
mod_http2.so
mod_unixd.so
mod_heartbeat.so
mod_heartmonitor.so
mod_status.so
mod_info.so
mod_cgid.so
mod_cgi.so
mod_dir.so
mod_alias.so
mod_rewrite.so

and the usual test modules:

mod_eat_post.so
mod_input_body_filter.so
mod_test_pass_brigade.so
mod_echo_post.so
mod_nntp_like.so
mod_fold.so
mod_client_add_filter.so
mod_memory_track.so
mod_test_ssl.so
mod_test_apr_uri.so
mod_list_modules.so
mod_random_chunk.so
mod_authany.so
mod_test_utilities.so
mod_echo_post_chunk.so
mod_test_rwrite.so
mod_mime.so
mod_alias.so


I don't know how to correctly distinguish a real 

Re: Failing http2.t in 2.4.36 [Was: NOTICE: Intent to T 2.4.36]

[Stefan Eissing]

Hi Rainer,

according to the log, the h2 code must be in the H2_SESSION_ST_BUSY state and 
the only cause I see is the same as you, namely an unexpected status from 
h2_session_read(), which should come via

status = ap_get_brigade(c->input_filters,
session->bbtmp, AP_MODE_READBYTES,
block? APR_BLOCK_READ : APR_NONBLOCK_READ,
H2MAX(APR_BUCKET_BUFF_SIZE, readlen));

block is 0 here and readlen should be (unless reconfigured via 
H2StreamMaxMemSize) 32kb.

Maybe you could just add a log line there to see what ap_get_brigade() returned 
there?

Strange.

-Stefan

> Am 13.10.2018 um 13:14 schrieb Rainer Jung :
> 
> Hi Stefan,
> 
> Am 10.10.2018 um 16:04 schrieb Stefan Eissing:
>>> Am 10.10.2018 um 15:06 schrieb Joe Orton :
>>> 
>>> I believe that t/modules/http2.t is dying in this:
>>> 
>>>my $old_ref = \&{ 'AnyEvent::TLS::_get_session' };
>>>*{ 'AnyEvent::TLS::_get_session' } = sub($$;$$) {
>>> 
>>> piece of magic which I don't understand but possibly needs updating for
>>> TLSv1.3? Session handling is different now... everything is broken.
>> I think there was no official way to add SNI to AnyEvent and I had to hack 
>> this. Unless anyone has another suggestion, I am in favour of removing the 
>> t/modules/http2.t again.
> 
> Note that if I manually send http2 requests using a recent curl, I get 
> failures as well (for 2.4.36).
> 
> The t/modules/http2.t indeed fails for each https test, even the simple first 
> one retrieving / and checking for status 200. One bug seems to me in the test 
> script, that it fails silently and simply notes that not all tests have run 
> at the end.
> 
> But if I only start the server using "t/TEST -start-httpd" and then run a 
> curl test request against the h2 port 8557, I get failures as well. The 
> server was build with TLS 1.3 support, but the failures occur with an 1.3 
> client but also with an 1.2 client (different builds of curl). I marked below 
> lines probably indicating the failure with  .
> 
> Here are details:
> 
> curl TLS 1.3 client output
> ==
> 
> *   Trying 127.0.0.1...
> * TCP_NODELAY set
> * Connected to localhost (127.0.0.1) port 8557 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> * TLSv1.3 (IN), TLS handshake, Server hello (2):
> * TLSv1.3 (IN), TLS handshake, [no content] (0):
> * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
> * TLSv1.3 (IN), TLS handshake, [no content] (0):
> * TLSv1.3 (IN), TLS handshake, Certificate (11):
> * TLSv1.3 (IN), TLS handshake, [no content] (0):
> * TLSv1.3 (IN), TLS handshake, CERT verify (15):
> * TLSv1.3 (IN), TLS handshake, [no content] (0):
> * TLSv1.3 (IN), TLS handshake, Finished (20):
> * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
> * TLSv1.3 (OUT), TLS handshake, [no content] (0):
> * TLSv1.3 (OUT), TLS handshake, Finished (20):
> * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
> * ALPN, server accepted to use h2
> * Server certificate:
> *  subject: C=US; ST=California; L=San Francisco; O=ASF; 
> OU=httpd-test/rsa-test; CN=localhost; emailAddress=test-...@httpd.apache.org
> *  start date: Oct 13 08:40:49 2018 GMT
> *  expire date: Oct 13 08:40:49 2019 GMT
> *  issuer: C=US; ST=California; L=San Francisco; O=ASF; OU=httpd-test; CN=ca; 
> emailAddress=test-...@httpd.apache.org
> *  SSL certificate verify result: self signed certificate in certificate 
> chain (19), continuing anyway.
> * Using HTTP2, server supports multi-use
> * Connection state changed (HTTP/2 confirmed)
> * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: 
> len=0
> * TLSv1.3 (OUT), TLS app data, [no content] (0):
> * TLSv1.3 (OUT), TLS app data, [no content] (0):
> * TLSv1.3 (OUT), TLS app data, [no content] (0):
> * Using Stream ID: 1 (easy handle 0x26ab080)
> * TLSv1.3 (OUT), TLS app data, [no content] (0):
> > GET / HTTP/2
> > Host: localhost:8557
> > User-Agent: curl/7.61.1
> > Accept: */*
> >
> * TLSv1.3 (IN), TLS handshake, [no content] (0):
> * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
> * TLSv1.3 (IN), TLS handshake, [no content] (0):
> * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
> * TLSv1.3 (IN), TLS app data, [no content] (0):
> * Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
> * TLSv1.3 (OUT), TLS app data, [no content] (0):
> * TLSv1.3 (IN), TLS app data, [no content] (0):
> * TLSv1.3 (IN), TLS alert, [no content] (0):
> * TLSv1.3 (IN), TLS alert, close notify (256):
> * Empty reply from server
> ^
> * Connection #0 to host localhost left intact
> curl: (52) Empty reply from server
> 
> curl TLS 1.3 server error log
> =
> 
> 12:37:23.974210 [example_hooks:notice] x_create_connection()
> 12:37:23.974598 [ssl:info] AH01964: Connection to child 66 established 
> (server localhost:8557)
> 

Re: Failing http2.t in 2.4.36 [Was: NOTICE: Intent to T 2.4.36]

[Rainer Jung]

Adding another debug snippet at the end ...

Am 13.10.2018 um 13:14 schrieb Rainer Jung:

Hi Stefan,

Am 10.10.2018 um 16:04 schrieb Stefan Eissing:



Am 10.10.2018 um 15:06 schrieb Joe Orton :

I believe that t/modules/http2.t is dying in this:

    my $old_ref = \&{ 'AnyEvent::TLS::_get_session' };
    *{ 'AnyEvent::TLS::_get_session' } = sub($$;$$) {

piece of magic which I don't understand but possibly needs updating for
TLSv1.3? Session handling is different now... everything is broken.


I think there was no official way to add SNI to AnyEvent and I had to 
hack this. Unless anyone has another suggestion, I am in favour of 
removing the t/modules/http2.t again.


Note that if I manually send http2 requests using a recent curl, I get 
failures as well (for 2.4.36).


The t/modules/http2.t indeed fails for each https test, even the simple 
first one retrieving / and checking for status 200. One bug seems to me 
in the test script, that it fails silently and simply notes that not all 
tests have run at the end.


But if I only start the server using "t/TEST -start-httpd" and then run 
a curl test request against the h2 port 8557, I get failures as well. 
The server was build with TLS 1.3 support, but the failures occur with 
an 1.3 client but also with an 1.2 client (different builds of curl). I 
marked below lines probably indicating the failure with  .


Here are details:

curl TLS 1.3 client output
==

*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8557 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=ASF; 
OU=httpd-test/rsa-test; CN=localhost; 
emailAddress=test-...@httpd.apache.org

*  start date: Oct 13 08:40:49 2018 GMT
*  expire date: Oct 13 08:40:49 2019 GMT
*  issuer: C=US; ST=California; L=San Francisco; O=ASF; OU=httpd-test; 
CN=ca; emailAddress=test-...@httpd.apache.org
*  SSL certificate verify result: self signed certificate in certificate 
chain (19), continuing anyway.

* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after 
upgrade: len=0

* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* Using Stream ID: 1 (easy handle 0x26ab080)
* TLSv1.3 (OUT), TLS app data, [no content] (0):
 > GET / HTTP/2
 > Host: localhost:8557
 > User-Agent: curl/7.61.1
 > Accept: */*
 >
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS alert, [no content] (0):
* TLSv1.3 (IN), TLS alert, close notify (256):
* Empty reply from server
^
* Connection #0 to host localhost left intact
curl: (52) Empty reply from server

curl TLS 1.3 server error log
=

12:37:23.974210 [example_hooks:notice] x_create_connection()
12:37:23.974598 [ssl:info] AH01964: Connection to child 66 established 
(server localhost:8557)
12:37:23.974726 [ssl:trace2] ssl_engine_rand.c(126): Server: Seeding 
PRNG with 144 bytes of entropy
12:37:23.974787 [ssl:trace6] ssl_engine_io.c(2077): Enabling 
non-blocking writes
12:37:23.974817 [ssl:trace3] ssl_engine_kernel.c(2191): OpenSSL: 
Handshake: start
12:37:23.974860 [ssl:trace3] ssl_engine_kernel.c(2200): OpenSSL: Loop: 
before SSL initialization
12:37:23.974886 [ssl:trace4] ssl_engine_io.c(2213): OpenSSL: read 5/5 
bytes from BIO#7fe690002b00 [mem: 7fe6900083c3] (BIO dump follows)
12:37:23.974917 [ssl:trace4] ssl_engine_io.c(2213): OpenSSL: read 
512/512 bytes from BIO#7fe690002b00 [mem: 7fe6900083c8] (BIO dump follows)
12:37:23.975115 [ssl:trace3] ssl_engine_kernel.c(2200): OpenSSL: Loop: 
before SSL initialization
12:37:23.975181 [ssl:debug] ssl_engine_kernel.c(2328): AH02043: SSL 
virtual host for 

Failing http2.t in 2.4.36 [Was: NOTICE: Intent to T 2.4.36]

[Rainer Jung]

Hi Stefan,

Am 10.10.2018 um 16:04 schrieb Stefan Eissing:



Am 10.10.2018 um 15:06 schrieb Joe Orton :

I believe that t/modules/http2.t is dying in this:

my $old_ref = \&{ 'AnyEvent::TLS::_get_session' };
*{ 'AnyEvent::TLS::_get_session' } = sub($$;$$) {

piece of magic which I don't understand but possibly needs updating for
TLSv1.3? Session handling is different now... everything is broken.


I think there was no official way to add SNI to AnyEvent and I had to hack 
this. Unless anyone has another suggestion, I am in favour of removing the 
t/modules/http2.t again.


Note that if I manually send http2 requests using a recent curl, I get 
failures as well (for 2.4.36).


The t/modules/http2.t indeed fails for each https test, even the simple 
first one retrieving / and checking for status 200. One bug seems to me 
in the test script, that it fails silently and simply notes that not all 
tests have run at the end.


But if I only start the server using "t/TEST -start-httpd" and then run 
a curl test request against the h2 port 8557, I get failures as well. 
The server was build with TLS 1.3 support, but the failures occur with 
an 1.3 client but also with an 1.2 client (different builds of curl). I 
marked below lines probably indicating the failure with  .


Here are details:

curl TLS 1.3 client output
==

*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8557 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=ASF; 
OU=httpd-test/rsa-test; CN=localhost; emailAddress=test-...@httpd.apache.org

*  start date: Oct 13 08:40:49 2018 GMT
*  expire date: Oct 13 08:40:49 2019 GMT
*  issuer: C=US; ST=California; L=San Francisco; O=ASF; OU=httpd-test; 
CN=ca; emailAddress=test-...@httpd.apache.org
*  SSL certificate verify result: self signed certificate in certificate 
chain (19), continuing anyway.

* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after 
upgrade: len=0

* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* Using Stream ID: 1 (easy handle 0x26ab080)
* TLSv1.3 (OUT), TLS app data, [no content] (0):
> GET / HTTP/2
> Host: localhost:8557
> User-Agent: curl/7.61.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS alert, [no content] (0):
* TLSv1.3 (IN), TLS alert, close notify (256):
* Empty reply from server
^
* Connection #0 to host localhost left intact
curl: (52) Empty reply from server

curl TLS 1.3 server error log
=

12:37:23.974210 [example_hooks:notice] x_create_connection()
12:37:23.974598 [ssl:info] AH01964: Connection to child 66 established 
(server localhost:8557)
12:37:23.974726 [ssl:trace2] ssl_engine_rand.c(126): Server: Seeding 
PRNG with 144 bytes of entropy
12:37:23.974787 [ssl:trace6] ssl_engine_io.c(2077): Enabling 
non-blocking writes
12:37:23.974817 [ssl:trace3] ssl_engine_kernel.c(2191): OpenSSL: 
Handshake: start
12:37:23.974860 [ssl:trace3] ssl_engine_kernel.c(2200): OpenSSL: Loop: 
before SSL initialization
12:37:23.974886 [ssl:trace4] ssl_engine_io.c(2213): OpenSSL: read 5/5 
bytes from BIO#7fe690002b00 [mem: 7fe6900083c3] (BIO dump follows)
12:37:23.974917 [ssl:trace4] ssl_engine_io.c(2213): OpenSSL: read 
512/512 bytes from BIO#7fe690002b00 [mem: 7fe6900083c8] (BIO dump follows)
12:37:23.975115 [ssl:trace3] ssl_engine_kernel.c(2200): OpenSSL: Loop: 
before SSL initialization
12:37:23.975181 [ssl:debug] ssl_engine_kernel.c(2328): AH02043: SSL 
virtual host for servername localhost found
12:37:23.975202 [ssl:debug] ssl_engine_kernel.c(2328): AH02043: SSL 

Re: NOTICE: Intent to T 2.4.36

[Stefan Eissing]

Just pushed a fix to github.

> Am 11.10.2018 um 13:21 schrieb Stefan Eissing :
> 
> That is a change in trunk which has not been ported to our 2.4.x branch. 
> Since the github mod_http2 is intended for people who place  the module into 
> their 2.4.x server, I did not add a mpm version check for this - yet.
> 
> 
> 
>> Am 11.10.2018 um 13:17 schrieb Jim Jagielski :
>> 
>> BTW, and I'm sure you know this, that this fails w/ trunk:
>> 
>> % make
>> Making all in mod_http2
>> CC   mod_http2_la-h2_alt_svc.lo
>> CC   mod_http2_la-h2_bucket_beam.lo
>> CC   mod_http2_la-h2_bucket_eos.lo
>> CC   mod_http2_la-h2_config.lo
>> CC   mod_http2_la-h2_conn.lo
>> h2_conn.c:311:8: error: no member named 'data_in_input_filters' in 'struct 
>> conn_rec'; did you mean 'clogging_input_filters'?
>>   c->data_in_input_filters  = 0;
>>  ^
>>  clogging_input_filters
>> /usr/local2/apache2/include/httpd.h:1178:18: note: 'clogging_input_filters' 
>> declared here
>>   unsigned int clogging_input_filters:1;
>>^
>> h2_conn.c:312:8: error: no member named 'data_in_output_filters' in 'struct 
>> conn_rec'
>>   c->data_in_output_filters = 0;
>>   ~  ^
>> 2 errors generated.
> 

Re: NOTICE: Intent to T 2.4.36

[Stefan Eissing]

That is a change in trunk which has not been ported to our 2.4.x branch. Since 
the github mod_http2 is intended for people who place  the module into their 
2.4.x server, I did not add a mpm version check for this - yet.



> Am 11.10.2018 um 13:17 schrieb Jim Jagielski :
> 
> BTW, and I'm sure you know this, that this fails w/ trunk:
> 
> % make
> Making all in mod_http2
>  CC   mod_http2_la-h2_alt_svc.lo
>  CC   mod_http2_la-h2_bucket_beam.lo
>  CC   mod_http2_la-h2_bucket_eos.lo
>  CC   mod_http2_la-h2_config.lo
>  CC   mod_http2_la-h2_conn.lo
> h2_conn.c:311:8: error: no member named 'data_in_input_filters' in 'struct 
> conn_rec'; did you mean 'clogging_input_filters'?
>c->data_in_input_filters  = 0;
>   ^
>   clogging_input_filters
> /usr/local2/apache2/include/httpd.h:1178:18: note: 'clogging_input_filters' 
> declared here
>unsigned int clogging_input_filters:1;
> ^
> h2_conn.c:312:8: error: no member named 'data_in_output_filters' in 'struct 
> conn_rec'
>c->data_in_output_filters = 0;
>~  ^
> 2 errors generated.

Re: NOTICE: Intent to T 2.4.36

[Jim Jagielski]

BTW, and I'm sure you know this, that this fails w/ trunk:

% make
Making all in mod_http2
  CC   mod_http2_la-h2_alt_svc.lo
  CC   mod_http2_la-h2_bucket_beam.lo
  CC   mod_http2_la-h2_bucket_eos.lo
  CC   mod_http2_la-h2_config.lo
  CC   mod_http2_la-h2_conn.lo
h2_conn.c:311:8: error: no member named 'data_in_input_filters' in 'struct 
conn_rec'; did you mean 'clogging_input_filters'?
c->data_in_input_filters  = 0;
   ^
   clogging_input_filters
/usr/local2/apache2/include/httpd.h:1178:18: note: 'clogging_input_filters' 
declared here
unsigned int clogging_input_filters:1;
 ^
h2_conn.c:312:8: error: no member named 'data_in_output_filters' in 'struct 
conn_rec'
c->data_in_output_filters = 0;
~  ^
2 errors generated.

Re: NOTICE: Intent to T 2.4.36

[Jim Jagielski]

Gotcha. Thx.

Re: NOTICE: Intent to T 2.4.36

[Stefan Eissing]

Sry, forgot that in my mail. It's described in "build from git" in the 
README.md, my mistake.

> Am 11.10.2018 um 12:42 schrieb Jim Jagielski :
> 
> I suggest you add
> 
>   'autoreconf -i'
> 
> as a prelim step.

Re: NOTICE: Intent to T 2.4.36

[Jim Jagielski]

I suggest you add

   'autoreconf -i'

as a prelim step.

Re: NOTICE: Intent to T 2.4.36

[Jim Jagielski]

% autoconf
configure.ac:41: error: possibly undefined macro: AM_INIT_AUTOMAKE
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
% ls
AUTHORS   DISCUSS   Makefile.am   README.md 
configure*mod-h2.xcodeproj/
COPYING   INSTALL   NEWS  autom4te.cache/   
configure.ac  mod_http2/
ChangeLog LICENSE   READMEconfig.logm4/ 
  test/
% ./configure --with-apxs=/usr/local2/apache2/bin/apxs
./configure: line 2332: syntax error near unexpected token `2.2.6'
./configure: line 2332: `LT_PREREQ(2.2.6)'
% autoconf --version
autoconf (GNU Autoconf) 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later

Re: NOTICE: Intent to T 2.4.36

[Stefan Eissing]

> Am 10.10.2018 um 21:30 schrieb Jim Jagielski :
> 
> 
> 
>> On Oct 10, 2018, at 10:04 AM, Stefan Eissing  
>> wrote:
>> I have started to convert the existing h2 testsuite in 
>> https://svn.apache.org/repos/asf/httpd/test/mod_h2/trunk from shell scripts 
>> to pytest in the github repro. I have a pytest suite for mod_md also in its 
>> github. 
>> 
>> My hope is to, one day, make those part of a httpd test suite, probably just 
>> by combining the separate standalone ones. Then we could have 
>> 'modules/ABC/test' as optional part of a module with a defined way to 
>> trigger them.
>> 
> 
> That would be great because it seems that almost no one is using it, or has 
> been able to get that test suite to work. I know I haven't.

I would love to get feedback to mod-h2 tests from 
https://github.com/icing/mod_h2.

If you have an apxs and the apache/apr header files, pytest, nghttp2 and curl 
on your system, checkout and

> autoconf
> ./configure --with-apxs=
> make
> make test

On my machine, this gives:

> make test
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C test/ test
rsync -a --exclude="*.in" e2e/conf/*.* 
/Users/sei/projects/mod-h2/test/gen/apache/conf
cd e2e && py.test
=== test 
session starts 

platform darwin -- Python 2.7.10, pytest-3.0.7, py-1.4.33, pluggy-0.4.0
rootdir: /Users/sei/projects/mod-h2/test/e2e, inifile:
collected 54 items

test_001_httpd_alive.py ..
test_002_curl_basics.py ..
test_003_curl_get.py .
test_004_curl_post.py 
test_100_conn_reuse.py .
test_101_ssl_reneg.py .
test_102_require.py ..
test_103_upgrade.py ...
test_200_header_invalid.py ...
test_201_header_conditional.py ..
test_202_trailer.py 
test_300_interim.py ...
test_400_push.py ..

 54 passed in 
13.25 seconds 

On my ubuntu image I get additionally:

= warnings 
summary =
test_001_httpd_alive.py::TestStore::()::test_001_02
  
/home/sei/.local/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:838:
 InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
certificate verification is strongly advised. See: 
https://urllib3.readthedocs.io/en/latest/security.html
InsecureRequestWarning)

-- Docs: http://doc.pytest.org/en/latest/warnings.html

as I am not using 'mkcert' as of yet and certs are self-signed.

Re: NOTICE: Intent to T 2.4.36

[Stefan Eissing]

My view: 

Shipping the TLSv1.3 support has risks, but we also need to 
enable people to have the latest in transport security. 

We paid attention to keeping the behaviour with older versions
of openssl unchanged and our test cases confirm that this is the
case - as far or short as they go.

People linking their server (or shipping a distro) with openssl 1.1.1
or the relevant libressl version for TLSv1.3 opt in to share that
risk, consciously.

We can mitigate the risk of such changes with
a) better test suites
b) a broader test community

While no one is prevented from voting on a release candidate, the time
window is too short for some people, I believe. 

My experience with making mod_http2 and mod_md available standalone 
on github is:
- it's a platform for people who make "bleeding-edge" packages available
  to a range of people who like to run on the latest and greatest.
- it broadens the test base considerably
- it simplifies testing of fixes
- it simplifies analysis of bug reports against our 2.4.x releases as
  issues are often reported more than once and I can point people to
  the github release for checking their bug against fixes already made.

The httpd project is, right now, not offering this. People can check out
2.4.x, sure, but fixes often trickle only in just before a release. Also,
the 2.4.x branch is not intended for testing a "hopeful" fix. And testing
the dev branch is not the same either.

So, it seems to me, as we are missing a 2.4.x-candy branch that is CTR
and where from RTC merges  with votes are done to 2.4.x. From 2.4.x-candy
we could tag "release-candidates" and provide our usual tar balls in 
a pretty automated way. They'd have not CVE relevant changes and need no
big announcements. I imagine Daniels scripts can make them easily.

For 2.4.36 it would have meant that we'd had people testing TLSv1.3 for
weeks now, in much broader settings. And it would not have cost us much.

Cheers,

Stefan

> Am 10.10.2018 um 22:45 schrieb Gregg Smith :
> 
> FWIW, I've been running 2.4.36-dev at revision 1841586 for 19 days 35 minutes 
> as of this writing and I've seen no problems up to this point. Granted I only 
> get a few thousand hits a day and not millions but so far so good. Haven't 
> had many tls/1.3 but I would assume that's to be expected for another week or 
> two until Chrome 70 and Firefox 63 come out.
> 
> Now off to build .36
> 
> On 10/10/2018 1:29 PM, William A Rowe Jr wrote:
>> On Wed, Oct 10, 2018, 14:53 Mark Blackman  wrote:
>>> 
>>> Does the TLSv1.3 support need to be production ready?
>>> 
>>> TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger
>>> existing behaviours, I would have assumed it’s relatively safe to release
>>> with caveats in the docs.
>>> Of course, once there’s more take-up of TLSv1.3, then the test suite needs
>>> to be useful. Getting real-world feedback about something completely new
>>> that doesn’t endanger existing behaviours outside of TLSv1.3 is probably
>>> worthwhile.
>>> 
>> Were it so easy...
>> It turns out httpd through 2.4.35 remain incompatible with changes to
>> openssl 1.1.1. This was disappointing from this project's perspective, the
>> issues are tracked on openssl project GitHub tickets.
>> If everything is good about this candidate, it should build and run against
>> 1.1.0, or 1.1.1, whether or not TLS 1.3 is enabled or avoided.
>> Ben Laurie last decade tried to address this with mod_tls, but mod_ssl
>> remains deeply tied to the internal behavior of libssl and libcrypto, to a
>> degree that it is effectively impossible to drop in 1.1.1 due to mechanical
>> changes in the protocol.
>> Dropping httpd 2.4.any into openssl 1.1.1 is a mess that several committers
>> have applied a great deal of attention to. We've undergone the same
>> problems with 1.1.0, 1.0.1, 1.0.0 and 0.9.8, so this didn't come as a
>> surprise.

Re: NOTICE: Intent to T 2.4.36

[Gregg Smith]

FWIW, I've been running 2.4.36-dev at revision 1841586 for 19 days 35 
minutes as of this writing and I've seen no problems up to this point. 
Granted I only get a few thousand hits a day and not millions but so far 
so good. Haven't had many tls/1.3 but I would assume that's to be 
expected for another week or two until Chrome 70 and Firefox 63 come out.


Now off to build .36

On 10/10/2018 1:29 PM, William A Rowe Jr wrote:

On Wed, Oct 10, 2018, 14:53 Mark Blackman  wrote:



Does the TLSv1.3 support need to be production ready?

TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger
existing behaviours, I would have assumed it’s relatively safe to release
with caveats in the docs.
Of course, once there’s more take-up of TLSv1.3, then the test suite needs
to be useful. Getting real-world feedback about something completely new
that doesn’t endanger existing behaviours outside of TLSv1.3 is probably
worthwhile.



Were it so easy...

It turns out httpd through 2.4.35 remain incompatible with changes to
openssl 1.1.1. This was disappointing from this project's perspective, the
issues are tracked on openssl project GitHub tickets.

If everything is good about this candidate, it should build and run against
1.1.0, or 1.1.1, whether or not TLS 1.3 is enabled or avoided.

Ben Laurie last decade tried to address this with mod_tls, but mod_ssl
remains deeply tied to the internal behavior of libssl and libcrypto, to a
degree that it is effectively impossible to drop in 1.1.1 due to mechanical
changes in the protocol.

Dropping httpd 2.4.any into openssl 1.1.1 is a mess that several committers
have applied a great deal of attention to. We've undergone the same
problems with 1.1.0, 1.0.1, 1.0.0 and 0.9.8, so this didn't come as a
surprise.

Re: NOTICE: Intent to T 2.4.36

[William A Rowe Jr]

On Wed, Oct 10, 2018, 14:53 Mark Blackman  wrote:

>
> Does the TLSv1.3 support need to be production ready?
>
> TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger
> existing behaviours, I would have assumed it’s relatively safe to release
> with caveats in the docs.
> Of course, once there’s more take-up of TLSv1.3, then the test suite needs
> to be useful. Getting real-world feedback about something completely new
> that doesn’t endanger existing behaviours outside of TLSv1.3 is probably
> worthwhile.
>

Were it so easy...

It turns out httpd through 2.4.35 remain incompatible with changes to
openssl 1.1.1. This was disappointing from this project's perspective, the
issues are tracked on openssl project GitHub tickets.

If everything is good about this candidate, it should build and run against
1.1.0, or 1.1.1, whether or not TLS 1.3 is enabled or avoided.

Ben Laurie last decade tried to address this with mod_tls, but mod_ssl
remains deeply tied to the internal behavior of libssl and libcrypto, to a
degree that it is effectively impossible to drop in 1.1.1 due to mechanical
changes in the protocol.

Dropping httpd 2.4.any into openssl 1.1.1 is a mess that several committers
have applied a great deal of attention to. We've undergone the same
problems with 1.1.0, 1.0.1, 1.0.0 and 0.9.8, so this didn't come as a
surprise.

Re: NOTICE: Intent to T 2.4.36

[Mark Blackman]

> On 10 Oct 2018, at 21:04, Jim Jagielski  wrote:
> 
>> 
>> Does the TLSv1.3 support need to be production ready?
>> 
>> TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger 
>> existing behaviours, I would have assumed it’s relatively safe to release 
>> with caveats in the docs. 
>> Of course, once there’s more take-up of TLSv1.3, then the test suite needs 
>> to be useful. Getting real-world feedback about something completely new 
>> that doesn’t endanger existing behaviours outside of TLSv1.3 is probably 
>> worthwhile.
> 
> The issue is that such a major feature enhancement touches a lot of code. 
> That can cause regressions.
> 
> Sometimes, some people try to reduce and restrict development and new 
> features using that as an argument. I, and numerous others, have consistently 
> disagreed with that as a convincing argument against adding stuff to 2.4.x. 
> In this particular situation, the "usual suspect(s)" were actually very 
> gung-ho on release, despite this being the exact kind of situation they would 
> normally balk against. I was noting the discrepancy and wondering the 
> reasoning…

Fair enough, I hadn’t checked to see how invasive the change was. I had assumed 
a lot of "#ifdef TLSV13” protecting current behaviours.

- Mark

Re: NOTICE: Intent to T 2.4.36

[William A Rowe Jr]

On Wed, Oct 10, 2018, 14:46 Jim Jagielski  wrote:

>
> On Oct 10, 2018, at 3:37 PM, William A Rowe Jr 
> wrote:
>
> On Wed, Oct 10, 2018, 14:28 Jim Jagielski  wrote:
>
>>
>> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr 
>> wrote:
>>
>> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski  wrote:
>>
>>> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
>>>
>>> If that's not ready for prime time, then why a release??
>>>
>>
>> AIUI, it isn't that httpd isn't ready for release, or even httpd-test
>> framework.
>> Until all the upstream CPAN modules behave reasonably with openssl 1.1.1
>> we will continue to see odd test results.
>>
>> The question is How Comfortable Are We That TLSv1.3 Support Is Production
>> Ready?
>>
>
"We" answer that question by voting on a release candidate.

This release seems very, very rushed to me. It seems strange that for
>> someone who balks against releasing s/w that hasn't been sufficiently
>> tested, or could cause regressions, and that the sole reason for this
>> particular release is TLSv1.3 support which seems insufficiently tested,
>> you are uncharacteristic cool with all this.
>>
>
> You elided the other half of my answer, you might want to read the entire
> comment.
>
> If we can exercise the same discipline with 2.4.37 that we showed with
> 2.4.35, then instead of producing a string of releases with a string of
> regressions, we still come out ahead for all users.
>
>
> You wrote:
>It was my hope we would push this out as 2.5.1-alpha, as now synced
>with 2.4.x branch, and let the eager early adopters help us uncover any
>unforeseen issues. Think we have a handle on, and have addressed
>the anticipated issues.
>
> So "eager early adopters" are OK with modules *you* wish to push out, even
> if they aren't quite ready, but NOT OK with modules and features others
> want, even if they also agree that they 'have a handle on, and have
> addressed the anticipated issues'
>

Do you actually remember what an -alpha release was? I know we've thrown
all the s&$# against the wall that would stick for the past 8 years,
waiting until it was announced to find out how much would slide back on the
floor.

What I just wrote above is that I think 2.4.36 is premature, but a release
for users to test is not. But since all of our discussions of reversioning
end up as immature as your silly provocation above, I've been done
debating. I haven't said yes or no to 2.4.36, I only started promoting the
idea of 2.5 alpha again, and even had a brief hope you supported the idea,
before you suggested throwing the contents of trunk en masse back into the
maintenance branch 2.4. That's when I checked out of the discussion, no
desire to keep beating my head against that brick wall.

In other words: would anyone else have suggested adding a major feature
> such as this, with somewhat questionable testing as well as it being the
> sole reason for said release, you would have complained and dismissed such
> explanations as 'eager early adopters' as facetious. I am glad that this is
> no longer the case and you have Seen The Light! As long as we can show an
> attempt at testing, and convince ourselves we have a "handle on" anything
> that might pop up, and addressed any anticipated issues, we can continue
> adding new features as we have been and still come out ahead for all users.
> Again, this is what I and others have been pushing and promoting for years
> so I am again glad that you have finally agreed.
>
> It's the inconsistency that is bothersome.
>

I've stated repeatedly that so long as httpd project members remain split
on offering a security and defect-fix maintenance branch, and in violent
opposition to moving forward with an enhancement 2.next or even 3.0
release, I've checked out from expressing an opinion on the way the project
manages the release branch, or the readiness of that branch, and I'll just
pay attention to trunk, which is interesting to me.

My only recent input was a plea to get out the first regression fix,
security and maintenance release out since 2.4.18 or so (looks that we
succeeded with .35), support for the proposal to start moving on
2.5.1-alpha from trunk, and an absolute insistence that all RMs observe
both the public STATUS as well as our internal security STATUS in preparing
and publicizing releases. Other details aren't worth endless debate threads.

When a 2.4 release is approved, I'm about to propose the same
feature/enhancement freeze for one subversion (so .38 following .37, should
the .36 candidate prove not ready yet) to address newly introduced (yet
undetected) defects, before we return to the is all pattern of chaotic
changes again.

Presenting this as 2.5.1-alpha and leveraging our users@ scrutiny still
makes more sense to me, and if the changes proved non-disruptive, shipping
these as 2.4.x afterwards.

Re: NOTICE: Intent to T 2.4.36

[Jim Jagielski]

> 
> Does the TLSv1.3 support need to be production ready?
> 
> TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger 
> existing behaviours, I would have assumed it’s relatively safe to release 
> with caveats in the docs. 
> Of course, once there’s more take-up of TLSv1.3, then the test suite needs to 
> be useful. Getting real-world feedback about something completely new that 
> doesn’t endanger existing behaviours outside of TLSv1.3 is probably 
> worthwhile.

The issue is that such a major feature enhancement touches a lot of code. That 
can cause regressions.

Sometimes, some people try to reduce and restrict development and new features 
using that as an argument. I, and numerous others, have consistently disagreed 
with that as a convincing argument against adding stuff to 2.4.x. In this 
particular situation, the "usual suspect(s)" were actually very gung-ho on 
release, despite this being the exact kind of situation they would normally 
balk against. I was noting the discrepancy and wondering the reasoning...

Re: NOTICE: Intent to T 2.4.36

[Mark Blackman]

> On 10 Oct 2018, at 20:28, Jim Jagielski  wrote:
> 
> 
> 
>> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr > > wrote:
>> 
>> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski > > wrote:
>> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
>> 
>> If that's not ready for prime time, then why a release??
>> 
>> AIUI, it isn't that httpd isn't ready for release, or even httpd-test 
>> framework.
>> Until all the upstream CPAN modules behave reasonably with openssl 1.1.1
>> we will continue to see odd test results.
> 
> The question is How Comfortable Are We That TLSv1.3 Support Is Production 
> Ready?
> 
> This release seems very, very rushed to me. It seems strange that for someone 
> who balks against releasing s/w that hasn't been sufficiently tested, or 
> could cause regressions, and that the sole reason for this particular release 
> is TLSv1.3 support which seems insufficiently tested, you are 
> uncharacteristic cool with all this.

Does the TLSv1.3 support need to be production ready?

TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger 
existing behaviours, I would have assumed it’s relatively safe to release with 
caveats in the docs. 
Of course, once there’s more take-up of TLSv1.3, then the test suite needs to 
be useful. Getting real-world feedback about something completely new that 
doesn’t endanger existing behaviours outside of TLSv1.3 is probably worthwhile.

- Mark

Re: NOTICE: Intent to T 2.4.36

[Jim Jagielski]

FWIW, I am NOT proposing that. Nor would I have the right to do so.

> On Oct 10, 2018, at 3:50 PM, Daniel Ruggeri  wrote:
> 
> On 2018-10-10 14:01, William A Rowe Jr wrote:
>> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski  wrote:
>>> I thought the whole intent for a quick 2.4.36 was for TLSv1.3
>>> support.
>>> If that's not ready for prime time, then why a release??
>> AIUI, it isn't that httpd isn't ready for release, or even httpd-test
>> framework.
>> Until all the upstream CPAN modules behave reasonably with openssl
>> 1.1.1
>> we will continue to see odd test results.
>> It was my hope we would push this out as 2.5.1-alpha, as now synced
>> with 2.4.x branch, and let the eager early adopters help us uncover
>> any
>> unforeseen issues. Think we have a handle on, and have addressed
>> the anticipated issues.
> 
> Right, my understanding is that this is more around the test suite and how it 
> does the testing rather than the project itself. If that's not the case, and 
> httpd itself isn't ready, I'm OK with aborting the release process.
> 
> -- 
> Daniel Ruggeri

Re: NOTICE: Intent to T 2.4.36

[Daniel Ruggeri]

On 2018-10-10 14:01, William A Rowe Jr wrote:

On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski  wrote:


I thought the whole intent for a quick 2.4.36 was for TLSv1.3
support.

If that's not ready for prime time, then why a release??


AIUI, it isn't that httpd isn't ready for release, or even httpd-test
framework.
Until all the upstream CPAN modules behave reasonably with openssl
1.1.1
we will continue to see odd test results.

It was my hope we would push this out as 2.5.1-alpha, as now synced
with 2.4.x branch, and let the eager early adopters help us uncover
any
unforeseen issues. Think we have a handle on, and have addressed
the anticipated issues.


Right, my understanding is that this is more around the test suite and 
how it does the testing rather than the project itself. If that's not 
the case, and httpd itself isn't ready, I'm OK with aborting the release 
process.


--
Daniel Ruggeri

Re: NOTICE: Intent to T 2.4.36

[Jim Jagielski]

> On Oct 10, 2018, at 3:37 PM, William A Rowe Jr  wrote:
> 
> On Wed, Oct 10, 2018, 14:28 Jim Jagielski  > wrote:
> 
> 
>> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr > > wrote:
>> 
>> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski > > wrote:
>> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
>> 
>> If that's not ready for prime time, then why a release??
>> 
>> AIUI, it isn't that httpd isn't ready for release, or even httpd-test 
>> framework.
>> Until all the upstream CPAN modules behave reasonably with openssl 1.1.1
>> we will continue to see odd test results.
> 
> The question is How Comfortable Are We That TLSv1.3 Support Is Production 
> Ready?
> 
> This release seems very, very rushed to me. It seems strange that for someone 
> who balks against releasing s/w that hasn't been sufficiently tested, or 
> could cause regressions, and that the sole reason for this particular release 
> is TLSv1.3 support which seems insufficiently tested, you are 
> uncharacteristic cool with all this.
> 
> You elided the other half of my answer, you might want to read the entire 
> comment.
> 
> If we can exercise the same discipline with 2.4.37 that we showed with 
> 2.4.35, then instead of producing a string of releases with a string of 
> regressions, we still come out ahead for all users.

You wrote:
   It was my hope we would push this out as 2.5.1-alpha, as now synced
   with 2.4.x branch, and let the eager early adopters help us uncover any
   unforeseen issues. Think we have a handle on, and have addressed
   the anticipated issues.

So "eager early adopters" are OK with modules *you* wish to push out, even if 
they aren't quite ready, but NOT OK with modules and features others want, even 
if they also agree that they 'have a handle on, and have addressed the 
anticipated issues'

In other words: would anyone else have suggested adding a major feature such as 
this, with somewhat questionable testing as well as it being the sole reason 
for said release, you would have complained and dismissed such explanations as 
'eager early adopters' as facetious. I am glad that this is no longer the case 
and you have Seen The Light! As long as we can show an attempt at testing, and 
convince ourselves we have a "handle on" anything that might pop up, and 
addressed any anticipated issues, we can continue adding new features as we 
have been and still come out ahead for all users. Again, this is what I and 
others have been pushing and promoting for years so I am again glad that you 
have finally agreed.

It's the inconsistency that is bothersome.

Re: NOTICE: Intent to T 2.4.36

[William A Rowe Jr]

On Wed, Oct 10, 2018, 09:04 Stefan Eissing 
wrote:

>
> Since each pytest module starts httpd and stops it again, the config files
> can be very local to the tests being done. That makes them quite easy to
> understand and startup times very short.
>

Sadly, that's an enormous regression from the perl-framework. You'll note
that our suite can be started in server mode on a significantly limited
test host environment, and the tests applied from a more comprehensive test
client instance. This proved especially helpful on aix, hpux and other odd
ball architectures when they were part of my focus.

>

Re: NOTICE: Intent to T 2.4.36

[William A Rowe Jr]

On Wed, Oct 10, 2018, 14:28 Jim Jagielski  wrote:

>
>
> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr 
> wrote:
>
> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski  wrote:
>
>> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
>>
>> If that's not ready for prime time, then why a release??
>>
>
> AIUI, it isn't that httpd isn't ready for release, or even httpd-test
> framework.
> Until all the upstream CPAN modules behave reasonably with openssl 1.1.1
> we will continue to see odd test results.
>
>
> The question is How Comfortable Are We That TLSv1.3 Support Is Production
> Ready?
>
> This release seems very, very rushed to me. It seems strange that for
> someone who balks against releasing s/w that hasn't been sufficiently
> tested, or could cause regressions, and that the sole reason for this
> particular release is TLSv1.3 support which seems insufficiently tested,
> you are uncharacteristic cool with all this.
>

You elided the other half of my answer, you might want to read the entire
comment.

If we can exercise the same discipline with 2.4.37 that we showed with
2.4.35, then instead of producing a string of releases with a string of
regressions, we still come out ahead for all users.

Re: NOTICE: Intent to T 2.4.36

[Jim Jagielski]

> On Oct 10, 2018, at 10:04 AM, Stefan Eissing  
> wrote:
> I have started to convert the existing h2 testsuite in 
> https://svn.apache.org/repos/asf/httpd/test/mod_h2/trunk from shell scripts 
> to pytest in the github repro. I have a pytest suite for mod_md also in its 
> github. 
> 
> My hope is to, one day, make those part of a httpd test suite, probably just 
> by combining the separate standalone ones. Then we could have 
> 'modules/ABC/test' as optional part of a module with a defined way to trigger 
> them.
> 

That would be great because it seems that almost no one is using it, or has 
been able to get that test suite to work. I know I haven't.

Re: NOTICE: Intent to T 2.4.36

[Jim Jagielski]

> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr  wrote:
> 
> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski  > wrote:
> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
> 
> If that's not ready for prime time, then why a release??
> 
> AIUI, it isn't that httpd isn't ready for release, or even httpd-test 
> framework.
> Until all the upstream CPAN modules behave reasonably with openssl 1.1.1
> we will continue to see odd test results.

The question is How Comfortable Are We That TLSv1.3 Support Is Production Ready?

This release seems very, very rushed to me. It seems strange that for someone 
who balks against releasing s/w that hasn't been sufficiently tested, or could 
cause regressions, and that the sole reason for this particular release is 
TLSv1.3 support which seems insufficiently tested, you are uncharacteristic 
cool with all this.

Re: NOTICE: Intent to T 2.4.36

[William A Rowe Jr]

On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski  wrote:

> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
>
> If that's not ready for prime time, then why a release??
>

AIUI, it isn't that httpd isn't ready for release, or even httpd-test
framework.
Until all the upstream CPAN modules behave reasonably with openssl 1.1.1
we will continue to see odd test results.

It was my hope we would push this out as 2.5.1-alpha, as now synced
with 2.4.x branch, and let the eager early adopters help us uncover any
unforeseen issues. Think we have a handle on, and have addressed
the anticipated issues.

Re: NOTICE: Intent to T 2.4.36

[Daniel Ruggeri]

On 2018-10-10 07:30, Joe Orton wrote:

On Tue, Oct 09, 2018 at 03:29:49PM -0500, Daniel Ruggeri wrote:

Hi, all;
   I ran through my usual testing routine, this time with OpenSSL 
1.1.1, but
found several test failures. In the past, these issues have been 
isolated to
my environment so I just wanted to drop a line to see if anyone has 
run the
test suite against 2.4.x lately and can corroborate this result? If 
not, I

can debug my environment.


TLSv1.3 testing is still a mess with OpenSSL 1.1.1, sorry.  I have
updated the test suite just now to disable TLSv1.3 testing for most
people.  We need updates to Net::SSLeay (the latest upstream has the
patch) and IO::Socket::SSL, but the latter is not patched upstream, so 
I

can't make an accurate test for that yet.

At worst, forcibly testing with:

  ./t/TEST -sslproto 'all -TLSv1.2'

should now be possible.

(If using an existing check-out of the test suite don't forget to 
re-run

"make" before running ./t/TEST -conf to regenerate the config...)

Let me know if that's not made any difference for you.

I don't know why t/modules/http2.t is failing but I see that here too.


Thanks Joe and Bill.

Yep, when flipping back over to OpenSSL 1.1.0i, everything works A-OK. 
Even the H2 failure irons itself out. It's a bummer to hear TLS 1.3 
testing isn't up to snuff with this being the major feature of the 
release.


I also just wiped the environment, recompiled everything from scratch 
(same versions noted below) and reran the tests with the latest test 
framework and see that the recent changes to the framework leave only 
the failing h2 test (which doesn't happen w/ 1.1.0i). So... I think it 
was indeed localized to the test framework.


I'm also happy to see the H2 EOS fix in, too!

So... I think I'm content with the results and am ready to T!



Regards, Joe




Test Summary Report
---
t/modules/http2.t (Wstat: 0 Tests: 24 Failed: 0)
  Parse errors: Bad plan.  You planned 52 tests but ran 24.
t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2)
  Failed tests:  3-4
t/ssl/basicauth.t (Wstat: 0 Tests: 4 Failed: 2)
  Failed tests:  2-3
t/ssl/env.t   (Wstat: 0 Tests: 30 Failed: 15)
  Failed tests:  16-30
t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4)
  Failed tests:  1-4
t/ssl/fakeauth.t  (Wstat: 0 Tests: 3 Failed: 2)
  Failed tests:  2-3
t/ssl/ocsp.t  (Wstat: 0 Tests: 3 Failed: 1)
  Failed test:  3
t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 3)
  Failed tests:  2, 5, 9
t/ssl/varlookup.t (Wstat: 0 Tests: 83 Failed: 83)
  Failed tests:  1-83
t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1)
  Failed test:  2
Files=186, Tests=8857, 101 wallclock secs ( 1.86 usr  0.28 sys + 48.46 
cusr

11.08 csys = 61.68 CPU)


Versions at play were:
system:
  kernel:
name: Linux
release: 3.16.0-4-amd64
version: #1 SMP Debian 3.16.51-3 (2017-12-13)
machine: x86_64

  libraries:
openssl: "1.1.1"
openldap: "2.4.46"
apr: "1.6.5"
apr-util: "1.6.1"
iconv: "1.2.2"
brotli: "1.0.6"
nghttp2: "1.34.0"
zlib: "1.2.11"
pcre: "8.42"
libxml2: "2.9.8"
php: "5.6.38"
lua: "5.3.5"
curl: "7.61.1"


Anything look obviously crazy/wrong?

--
Daniel Ruggeri

On 2018-10-09 06:36, Daniel Ruggeri wrote:
> Hi, all;
>  Barring any major disagreement in the next several hours, I intend to
> T our next version later today or early tomorrow.
>
> Hooray for TLS 1.3!
> --
> Daniel Ruggeri


--
Daniel Ruggeri

Re: NOTICE: Intent to T 2.4.36

[Stefan Eissing]

Just in case of tl;dr:

The fix is proposed for backport, 1 vote is missing, would be nice to have in 
2.4.36

Thanks, Stefan

> Am 10.10.2018 um 10:47 schrieb Stefan Eissing :
> 
> I have a report of h2 missing an EOS flag on certain conditions related to 
> php served resources. Trying to reproduce. First such report came before 
> 2.4.35. I'd say, if I cannot progress on this today, then please go ahead and 
> tag. Will report later.
> 
> -Stefan
> 
>> Am 09.10.2018 um 22:29 schrieb Daniel Ruggeri :
>> 
>> Hi, all;
>>  I ran through my usual testing routine, this time with OpenSSL 1.1.1, but 
>> found several test failures. In the past, these issues have been isolated to 
>> my environment so I just wanted to drop a line to see if anyone has run the 
>> test suite against 2.4.x lately and can corroborate this result? If not, I 
>> can debug my environment.
>> 
>> Test Summary Report
>> ---
>> t/modules/http2.t (Wstat: 0 Tests: 24 Failed: 0)
>> Parse errors: Bad plan.  You planned 52 tests but ran 24.
>> t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2)
>> Failed tests:  3-4
>> t/ssl/basicauth.t (Wstat: 0 Tests: 4 Failed: 2)
>> Failed tests:  2-3
>> t/ssl/env.t   (Wstat: 0 Tests: 30 Failed: 15)
>> Failed tests:  16-30
>> t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4)
>> Failed tests:  1-4
>> t/ssl/fakeauth.t  (Wstat: 0 Tests: 3 Failed: 2)
>> Failed tests:  2-3
>> t/ssl/ocsp.t  (Wstat: 0 Tests: 3 Failed: 1)
>> Failed test:  3
>> t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 3)
>> Failed tests:  2, 5, 9
>> t/ssl/varlookup.t (Wstat: 0 Tests: 83 Failed: 83)
>> Failed tests:  1-83
>> t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1)
>> Failed test:  2
>> Files=186, Tests=8857, 101 wallclock secs ( 1.86 usr  0.28 sys + 48.46 cusr 
>> 11.08 csys = 61.68 CPU)
>> 
>> 
>> Versions at play were:
>> system:
>> kernel:
>>   name: Linux
>>   release: 3.16.0-4-amd64
>>   version: #1 SMP Debian 3.16.51-3 (2017-12-13)
>>   machine: x86_64
>> 
>> libraries:
>>   openssl: "1.1.1"
>>   openldap: "2.4.46"
>>   apr: "1.6.5"
>>   apr-util: "1.6.1"
>>   iconv: "1.2.2"
>>   brotli: "1.0.6"
>>   nghttp2: "1.34.0"
>>   zlib: "1.2.11"
>>   pcre: "8.42"
>>   libxml2: "2.9.8"
>>   php: "5.6.38"
>>   lua: "5.3.5"
>>   curl: "7.61.1"
>> 
>> 
>> Anything look obviously crazy/wrong?
>> 
>> -- 
>> Daniel Ruggeri
>> 
>> On 2018-10-09 06:36, Daniel Ruggeri wrote:
>>> Hi, all;
>>> Barring any major disagreement in the next several hours, I intend to
>>> T our next version later today or early tomorrow.
>>> Hooray for TLS 1.3!
>>> --
>>> Daniel Ruggeri
> 

Re: NOTICE: Intent to T 2.4.36

[Stefan Eissing]

> Am 10.10.2018 um 15:06 schrieb Joe Orton :
> 
> I believe that t/modules/http2.t is dying in this:
> 
>my $old_ref = \&{ 'AnyEvent::TLS::_get_session' };
>*{ 'AnyEvent::TLS::_get_session' } = sub($$;$$) {
> 
> piece of magic which I don't understand but possibly needs updating for 
> TLSv1.3? Session handling is different now... everything is broken.

I think there was no official way to add SNI to AnyEvent and I had to hack 
this. Unless anyone has another suggestion, I am in favour of removing the 
t/modules/http2.t again.

I have started to convert the existing h2 testsuite in 
https://svn.apache.org/repos/asf/httpd/test/mod_h2/trunk from shell scripts to 
pytest in the github repro. I have a pytest suite for mod_md also in its 
github. 

My hope is to, one day, make those part of a httpd test suite, probably just by 
combining the separate standalone ones. Then we could have 'modules/ABC/test' 
as optional part of a module with a defined way to trigger them.

Since each pytest module starts httpd and stops it again, the config files can 
be very local to the tests being done. That makes them quite easy to understand 
and startup times very short.

As for the certificates on a test host, I'd like to use 
https://github.com/FiloSottile/mkcert. That runs on MacOS, Linux and Windows. 
Not sure about the other OS we run on. More and more clients refuse to drop 
certificate verification or at least generate verbose warnings, so mkcert seems 
a good way to go.

-Stefan

Re: NOTICE: Intent to T 2.4.36

[Stefan Eissing]

Thanks, Joe. Tried to get it running on my Ubuntu 18.04 LTS image, but there I 
cannot even get the necessary Perl modules installed via CPAN.

I give up.

> Am 10.10.2018 um 15:06 schrieb Joe Orton :
> 
> On Wed, Oct 10, 2018 at 02:52:13PM +0200, Stefan Eissing wrote:
>> I cannot get the test framework to properly initialise any longer (MacOS 
>> 10.14):
>> 
>>> t/TEST -clean
>>> t/TEST
>> [warning] setting ulimit to allow core files
>> ulimit -c unlimited; /usr/bin/perl 
>> /Users/sei/projects/httpd/test/framework/trunk/t/TEST
>> [warning] generating SSL CA for asf
>> [   info] openssl req -new -x509 -keyout keys/ca.pem -out certs/ca.crt -days 
>> 365 -config conf/ca.cnf
>> Generating a 2048 bit RSA private key
>> ..+++
>> ..+++
>> writing new private key to 'keys/ca.pem'
>> -
>> problems making Certificate Request
>> 4620047980:error:0DFFF07A:asn1 encoding routines:CRYPTO_internal:first num 
>> too 
>> large:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.200.4/libressl-2.6/crypto/asn1/a_object.c:112:
>> 4620047980:error:0BFFF077:x509 certificate routines:CRYPTO_internal:invalid 
>> field 
>> name:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.200.4/libressl-2.6/crypto/x509/x509name.c:303:name=Email
>> [  error] configure() has failed:
>> system req -new -x509 -keyout keys/ca.pem -out certs/ca.crt -days 365 
>> -config conf/ca.cnf failed (exit status=1) at 
>> /Users/sei/projects/httpd/test/framework/trunk/Apache-Test/lib/Apache/TestSSLCA.pm
>>  line 216.
>> 
>> [warning] forcing Apache::TestConfig object save
>> [warning] run 't/TEST -clean' to clean up before continuing
>> 
>> Any tips?
> 
> Did you start from a fresh checkout?  I can't remember seeing that 
> particular error before but the whole thing is fragile as heck.
> 
> I believe that t/modules/http2.t is dying in this:
> 
>my $old_ref = \&{ 'AnyEvent::TLS::_get_session' };
>*{ 'AnyEvent::TLS::_get_session' } = sub($$;$$) {
> 
> piece of magic which I don't understand but possibly needs updating for 
> TLSv1.3? Session handling is different now... everything is broken.
> 
> The last output I get is:
> 
> ok 24
> test case: TC0001, expecting 200: GET https://localhost:8557/
> test case: VHOST000, expecting 200: GET https://localhost:8557/
> setting host_name to localhost:8557
> Failed 28/52 subtests 
> 
> so it looks like the perl script died completely somewhere around that 
> point.  My fedora 29 chroot has:
> 
> # rpm -q perl-AnyEvent openssl perl-interpreter
> perl-AnyEvent-7.14-7.fc29.x86_64
> openssl-1.1.1-3.fc29.x86_64
> perl-interpreter-5.28.0-423.fc29.x86_64
> 
> fwiw.

Re: NOTICE: Intent to T 2.4.36

[Joe Orton]

On Wed, Oct 10, 2018 at 02:52:13PM +0200, Stefan Eissing wrote:
> I cannot get the test framework to properly initialise any longer (MacOS 
> 10.14):
> 
> > t/TEST -clean
> > t/TEST
> [warning] setting ulimit to allow core files
> ulimit -c unlimited; /usr/bin/perl 
> /Users/sei/projects/httpd/test/framework/trunk/t/TEST
> [warning] generating SSL CA for asf
> [   info] openssl req -new -x509 -keyout keys/ca.pem -out certs/ca.crt -days 
> 365 -config conf/ca.cnf
> Generating a 2048 bit RSA private key
> ..+++
> ..+++
> writing new private key to 'keys/ca.pem'
> -
> problems making Certificate Request
> 4620047980:error:0DFFF07A:asn1 encoding routines:CRYPTO_internal:first num 
> too 
> large:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.200.4/libressl-2.6/crypto/asn1/a_object.c:112:
> 4620047980:error:0BFFF077:x509 certificate routines:CRYPTO_internal:invalid 
> field 
> name:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.200.4/libressl-2.6/crypto/x509/x509name.c:303:name=Email
> [  error] configure() has failed:
> system req -new -x509 -keyout keys/ca.pem -out certs/ca.crt -days 365 -config 
> conf/ca.cnf failed (exit status=1) at 
> /Users/sei/projects/httpd/test/framework/trunk/Apache-Test/lib/Apache/TestSSLCA.pm
>  line 216.
> 
> [warning] forcing Apache::TestConfig object save
> [warning] run 't/TEST -clean' to clean up before continuing
> 
> Any tips?

Did you start from a fresh checkout?  I can't remember seeing that 
particular error before but the whole thing is fragile as heck.

I believe that t/modules/http2.t is dying in this:

my $old_ref = \&{ 'AnyEvent::TLS::_get_session' };
*{ 'AnyEvent::TLS::_get_session' } = sub($$;$$) {

piece of magic which I don't understand but possibly needs updating for 
TLSv1.3? Session handling is different now... everything is broken.

The last output I get is:

ok 24
test case: TC0001, expecting 200: GET https://localhost:8557/
test case: VHOST000, expecting 200: GET https://localhost:8557/
setting host_name to localhost:8557
Failed 28/52 subtests 

so it looks like the perl script died completely somewhere around that 
point.  My fedora 29 chroot has:

# rpm -q perl-AnyEvent openssl perl-interpreter
perl-AnyEvent-7.14-7.fc29.x86_64
openssl-1.1.1-3.fc29.x86_64
perl-interpreter-5.28.0-423.fc29.x86_64

fwiw.

Re: NOTICE: Intent to T 2.4.36

[Joe Orton]

On Tue, Oct 09, 2018 at 03:29:49PM -0500, Daniel Ruggeri wrote:
> Hi, all;
>I ran through my usual testing routine, this time with OpenSSL 1.1.1, but
> found several test failures. In the past, these issues have been isolated to
> my environment so I just wanted to drop a line to see if anyone has run the
> test suite against 2.4.x lately and can corroborate this result? If not, I
> can debug my environment.

TLSv1.3 testing is still a mess with OpenSSL 1.1.1, sorry.  I have 
updated the test suite just now to disable TLSv1.3 testing for most 
people.  We need updates to Net::SSLeay (the latest upstream has the 
patch) and IO::Socket::SSL, but the latter is not patched upstream, so I 
can't make an accurate test for that yet.

At worst, forcibly testing with:

  ./t/TEST -sslproto 'all -TLSv1.2'

should now be possible.

(If using an existing check-out of the test suite don't forget to re-run 
"make" before running ./t/TEST -conf to regenerate the config...)

Let me know if that's not made any difference for you.

I don't know why t/modules/http2.t is failing but I see that here too.

Regards, Joe


> 
> Test Summary Report
> ---
> t/modules/http2.t (Wstat: 0 Tests: 24 Failed: 0)
>   Parse errors: Bad plan.  You planned 52 tests but ran 24.
> t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2)
>   Failed tests:  3-4
> t/ssl/basicauth.t (Wstat: 0 Tests: 4 Failed: 2)
>   Failed tests:  2-3
> t/ssl/env.t   (Wstat: 0 Tests: 30 Failed: 15)
>   Failed tests:  16-30
> t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4)
>   Failed tests:  1-4
> t/ssl/fakeauth.t  (Wstat: 0 Tests: 3 Failed: 2)
>   Failed tests:  2-3
> t/ssl/ocsp.t  (Wstat: 0 Tests: 3 Failed: 1)
>   Failed test:  3
> t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 3)
>   Failed tests:  2, 5, 9
> t/ssl/varlookup.t (Wstat: 0 Tests: 83 Failed: 83)
>   Failed tests:  1-83
> t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1)
>   Failed test:  2
> Files=186, Tests=8857, 101 wallclock secs ( 1.86 usr  0.28 sys + 48.46 cusr
> 11.08 csys = 61.68 CPU)
> 
> 
> Versions at play were:
> system:
>   kernel:
> name: Linux
> release: 3.16.0-4-amd64
> version: #1 SMP Debian 3.16.51-3 (2017-12-13)
> machine: x86_64
> 
>   libraries:
> openssl: "1.1.1"
> openldap: "2.4.46"
> apr: "1.6.5"
> apr-util: "1.6.1"
> iconv: "1.2.2"
> brotli: "1.0.6"
> nghttp2: "1.34.0"
> zlib: "1.2.11"
> pcre: "8.42"
> libxml2: "2.9.8"
> php: "5.6.38"
> lua: "5.3.5"
> curl: "7.61.1"
> 
> 
> Anything look obviously crazy/wrong?
> 
> -- 
> Daniel Ruggeri
> 
> On 2018-10-09 06:36, Daniel Ruggeri wrote:
> > Hi, all;
> >  Barring any major disagreement in the next several hours, I intend to
> > T our next version later today or early tomorrow.
> > 
> > Hooray for TLS 1.3!
> > --
> > Daniel Ruggeri

Re: NOTICE: Intent to T 2.4.36

[Stefan Eissing]

I have a report of h2 missing an EOS flag on certain conditions related to php 
served resources. Trying to reproduce. First such report came before 2.4.35. 
I'd say, if I cannot progress on this today, then please go ahead and tag. Will 
report later.

-Stefan

> Am 09.10.2018 um 22:29 schrieb Daniel Ruggeri :
> 
> Hi, all;
>   I ran through my usual testing routine, this time with OpenSSL 1.1.1, but 
> found several test failures. In the past, these issues have been isolated to 
> my environment so I just wanted to drop a line to see if anyone has run the 
> test suite against 2.4.x lately and can corroborate this result? If not, I 
> can debug my environment.
> 
> Test Summary Report
> ---
> t/modules/http2.t (Wstat: 0 Tests: 24 Failed: 0)
>  Parse errors: Bad plan.  You planned 52 tests but ran 24.
> t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2)
>  Failed tests:  3-4
> t/ssl/basicauth.t (Wstat: 0 Tests: 4 Failed: 2)
>  Failed tests:  2-3
> t/ssl/env.t   (Wstat: 0 Tests: 30 Failed: 15)
>  Failed tests:  16-30
> t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4)
>  Failed tests:  1-4
> t/ssl/fakeauth.t  (Wstat: 0 Tests: 3 Failed: 2)
>  Failed tests:  2-3
> t/ssl/ocsp.t  (Wstat: 0 Tests: 3 Failed: 1)
>  Failed test:  3
> t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 3)
>  Failed tests:  2, 5, 9
> t/ssl/varlookup.t (Wstat: 0 Tests: 83 Failed: 83)
>  Failed tests:  1-83
> t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1)
>  Failed test:  2
> Files=186, Tests=8857, 101 wallclock secs ( 1.86 usr  0.28 sys + 48.46 cusr 
> 11.08 csys = 61.68 CPU)
> 
> 
> Versions at play were:
> system:
>  kernel:
>name: Linux
>release: 3.16.0-4-amd64
>version: #1 SMP Debian 3.16.51-3 (2017-12-13)
>machine: x86_64
> 
>  libraries:
>openssl: "1.1.1"
>openldap: "2.4.46"
>apr: "1.6.5"
>apr-util: "1.6.1"
>iconv: "1.2.2"
>brotli: "1.0.6"
>nghttp2: "1.34.0"
>zlib: "1.2.11"
>pcre: "8.42"
>libxml2: "2.9.8"
>php: "5.6.38"
>lua: "5.3.5"
>curl: "7.61.1"
> 
> 
> Anything look obviously crazy/wrong?
> 
> -- 
> Daniel Ruggeri
> 
> On 2018-10-09 06:36, Daniel Ruggeri wrote:
>> Hi, all;
>> Barring any major disagreement in the next several hours, I intend to
>> T our next version later today or early tomorrow.
>> Hooray for TLS 1.3!
>> --
>> Daniel Ruggeri

Re: NOTICE: Intent to T 2.4.36

[William A Rowe Jr]

You might want to review the thread following up svn commit: r1840585
back from Sept 12th w.r.t. some of these.

On Tue, Oct 9, 2018 at 3:29 PM Daniel Ruggeri  wrote:

> Hi, all;
> I ran through my usual testing routine, this time with OpenSSL 1.1.1,
> but found several test failures. In the past, these issues have been
> isolated to my environment so I just wanted to drop a line to see if
> anyone has run the test suite against 2.4.x lately and can corroborate
> this result? If not, I can debug my environment.
>
> Test Summary Report
> ---
> t/modules/http2.t (Wstat: 0 Tests: 24 Failed: 0)
>Parse errors: Bad plan.  You planned 52 tests but ran 24.
> t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2)
>Failed tests:  3-4
> t/ssl/basicauth.t (Wstat: 0 Tests: 4 Failed: 2)
>Failed tests:  2-3
> t/ssl/env.t   (Wstat: 0 Tests: 30 Failed: 15)
>Failed tests:  16-30
> t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4)
>Failed tests:  1-4
> t/ssl/fakeauth.t  (Wstat: 0 Tests: 3 Failed: 2)
>Failed tests:  2-3
> t/ssl/ocsp.t  (Wstat: 0 Tests: 3 Failed: 1)
>Failed test:  3
> t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 3)
>Failed tests:  2, 5, 9
> t/ssl/varlookup.t (Wstat: 0 Tests: 83 Failed: 83)
>Failed tests:  1-83
> t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1)
>Failed test:  2
> Files=186, Tests=8857, 101 wallclock secs ( 1.86 usr  0.28 sys + 48.46
> cusr 11.08 csys = 61.68 CPU)
>
>
> Versions at play were:
> system:
>kernel:
>  name: Linux
>  release: 3.16.0-4-amd64
>  version: #1 SMP Debian 3.16.51-3 (2017-12-13)
>  machine: x86_64
>
>libraries:
>  openssl: "1.1.1"
>  openldap: "2.4.46"
>  apr: "1.6.5"
>  apr-util: "1.6.1"
>  iconv: "1.2.2"
>  brotli: "1.0.6"
>  nghttp2: "1.34.0"
>  zlib: "1.2.11"
>  pcre: "8.42"
>  libxml2: "2.9.8"
>  php: "5.6.38"
>  lua: "5.3.5"
>  curl: "7.61.1"
>
>
> Anything look obviously crazy/wrong?
>
> --
> Daniel Ruggeri
>
> On 2018-10-09 06:36, Daniel Ruggeri wrote:
> > Hi, all;
> >  Barring any major disagreement in the next several hours, I intend to
> > T our next version later today or early tomorrow.
> >
> > Hooray for TLS 1.3!
> > --
> > Daniel Ruggeri
>

Re: NOTICE: Intent to T 2.4.36

[Daniel Ruggeri]

Hi, all;
   I ran through my usual testing routine, this time with OpenSSL 1.1.1, 
but found several test failures. In the past, these issues have been 
isolated to my environment so I just wanted to drop a line to see if 
anyone has run the test suite against 2.4.x lately and can corroborate 
this result? If not, I can debug my environment.


Test Summary Report
---
t/modules/http2.t (Wstat: 0 Tests: 24 Failed: 0)
  Parse errors: Bad plan.  You planned 52 tests but ran 24.
t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2)
  Failed tests:  3-4
t/ssl/basicauth.t (Wstat: 0 Tests: 4 Failed: 2)
  Failed tests:  2-3
t/ssl/env.t   (Wstat: 0 Tests: 30 Failed: 15)
  Failed tests:  16-30
t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4)
  Failed tests:  1-4
t/ssl/fakeauth.t  (Wstat: 0 Tests: 3 Failed: 2)
  Failed tests:  2-3
t/ssl/ocsp.t  (Wstat: 0 Tests: 3 Failed: 1)
  Failed test:  3
t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 3)
  Failed tests:  2, 5, 9
t/ssl/varlookup.t (Wstat: 0 Tests: 83 Failed: 83)
  Failed tests:  1-83
t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1)
  Failed test:  2
Files=186, Tests=8857, 101 wallclock secs ( 1.86 usr  0.28 sys + 48.46 
cusr 11.08 csys = 61.68 CPU)



Versions at play were:
system:
  kernel:
name: Linux
release: 3.16.0-4-amd64
version: #1 SMP Debian 3.16.51-3 (2017-12-13)
machine: x86_64

  libraries:
openssl: "1.1.1"
openldap: "2.4.46"
apr: "1.6.5"
apr-util: "1.6.1"
iconv: "1.2.2"
brotli: "1.0.6"
nghttp2: "1.34.0"
zlib: "1.2.11"
pcre: "8.42"
libxml2: "2.9.8"
php: "5.6.38"
lua: "5.3.5"
curl: "7.61.1"


Anything look obviously crazy/wrong?

--
Daniel Ruggeri

On 2018-10-09 06:36, Daniel Ruggeri wrote:

Hi, all;
 Barring any major disagreement in the next several hours, I intend to
T our next version later today or early tomorrow.

Hooray for TLS 1.3!
--
Daniel Ruggeri

Re: NOTICE: Intent to T 2.4.36

[Yann Ylavic]

Hi Daniel,

On Tue, Oct 9, 2018 at 1:36 PM Daniel Ruggeri  wrote:
>
> Barring any major disagreement in the next several hours, I intend to T our 
> next version later today or early tomorrow.

Thanks for proposing!

I wish we could include the two mod_ssl fixes (w/ missing votes) for 2.4.36.
Btw, there are accepted backport which are not merged yet.

Regards,
Yann.

NOTICE: Intent to T 2.4.36

[Daniel Ruggeri]

Hi, all;
  Barring any major disagreement in the next several hours, I intend to T our 
next version later today or early tomorrow.

Hooray for TLS 1.3!
-- 
Daniel Ruggeri