Re: [VOTE] Release httpd-2.4.43
On 2020-03-26 10:50, Daniel Ruggeri wrote: Hi, all; Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball as 2.4.43: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha1: 15d8605b094dfe5e283cd9e90770368dd14e26f2 *httpd-2.4.43.tar.gz sha256: 2624e92d89b20483caeffe514a7c7ba93ab13b650295ae330f01c35d5b50d87f *httpd-2.4.43.tar.gz sha512: d9879b8f8ef7d94dee1024e9c25b56d963a3b072520878a88a044629ad577c109a5456791b39016bf4f6672c04bf4a0e5cfd32381211e9acdc81d4a50b359e5e *httpd-2.4.43.tar.gz The SVN tag is '2.4.43' at r1875715. well https://alpha.genunix.com is acting strangely. On Solaris 10 I am seeing strange connection issues and am not yet sure what the problem is. May be related to : https://github.com/openssl/openssl/issues/11378 -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: OpenSSL 1.1.1e New EOF detection breaks session resumption
Thanks Rainer and Rüdiger, When 2.4.43 is GA, I ship it with 1.1.1e. When 1.1.1f is available : test and wait a week to ship it with 2.4.43. Regards, Steffen > Op 27 mrt. 2020 om 20:33 heeft Rainer Jung het > volgende geschreven: > > Am 27.03.2020 um 19:24 schrieb Steffen: >> A discussion started on Apachelounge about an possible issue with OpenSSL >> 1.1.1e ( https://www.apachelounge.com/viewtopic.php?p=38941#38941 ) >> This is the introduced new EOF in 1.1.1e : >> https://github.com/openssl/openssl/commit/db943f43a60d1b5b1277e4b5317e8f288e7a0a3a >> Discussion on OpenSSL is at https://github.com/openssl/openssl/issues/11378 >> I dot understand what is going on, but Daniel Stenberg (Curl) states : The >> "poorly-implemented HTTP/1.1 servers" are still out there and are being >> used. How common? Impossible to say. >> OpenSSL has a Patch with description : >> ... possible application breakage caused by a change in behavior introduced >> in 1.1.1e. It affects at least nginx, which logs error messages such as: >> nginx[16652]: [crit] 16675#0: *358 SSL_read() failed (SSL: error: >> 4095126:SSL routines:ssl3_read_n:unexpected eof while reading) while >> keepalive, client: , server: [::]:443 >> So looks that nginx is effected. >> My question is : >> *Is Apache effected ? * Looks not, because till now: Apachelounge has more >> then a week 2.4.41 available with 1.1.1e, which is downloaded over 50.000 >> times and no issues reported like this. > > I did a few hundred test suite runs on 5 platforms for the 2.4.42 release > candidate against OpenSSL 1.1.1e and noticed no special new ssl related > errors. > > So either our tests do not detect it or httpd does not have that problem. > > There will be a new OpenSSL 1.1.1f release next week. > > Regards, > > Rainer
Re: OpenSSL 1.1.1e New EOF detection breaks session resumption
On 3/27/20 7:24 PM, Steffen wrote: > > A discussion started on Apachelounge about an possible issue with OpenSSL > 1.1.1e > ( https://www.apachelounge.com/viewtopic.php?p=38941#38941 ) > > This is the introduced new EOF in 1.1.1e : > https://github.com/openssl/openssl/commit/db943f43a60d1b5b1277e4b5317e8f288e7a0a3a > > > Discussion on OpenSSL is at https://github.com/openssl/openssl/issues/11378 > > I dot understand what is going on, but Daniel Stenberg (Curl) states : The > "poorly-implemented HTTP/1.1 servers" are still out > there and are being used. How common? Impossible to say. > > > OpenSSL has a Patch with description : > ... possible application breakage caused by a change in behavior introduced > in 1.1.1e. It affects at least nginx, which logs > error messages such as: > nginx[16652]: [crit] 16675#0: *358 SSL_read() failed (SSL: error: > 4095126:SSL routines:ssl3_read_n:unexpected eof while reading) while > keepalive, client: , server: [::]:443 > > So looks that nginx is effected. > > My question is : > *Is Apache effected ? * Looks not, because till now: Apachelounge has more > then a week 2.4.41 available with 1.1.1e, which is > downloaded over 50.000 times and no issues reported like this. >From a quick look at the code I would say that we are not affected. Unless >ssl-unclean-shutdown (http://httpd.apache.org/docs/2.4/ssl/ssl_faq.html) is set and we did not detect a closed socket we sent a close_notify alert via modssl_smart_shutdown. Regards Rüdiger
Re: OpenSSL 1.1.1e New EOF detection breaks session resumption
Am 27.03.2020 um 19:24 schrieb Steffen: A discussion started on Apachelounge about an possible issue with OpenSSL 1.1.1e ( https://www.apachelounge.com/viewtopic.php?p=38941#38941 ) This is the introduced new EOF in 1.1.1e : https://github.com/openssl/openssl/commit/db943f43a60d1b5b1277e4b5317e8f288e7a0a3a Discussion on OpenSSL is at https://github.com/openssl/openssl/issues/11378 I dot understand what is going on, but Daniel Stenberg (Curl) states : The "poorly-implemented HTTP/1.1 servers" are still out there and are being used. How common? Impossible to say. OpenSSL has a Patch with description : ... possible application breakage caused by a change in behavior introduced in 1.1.1e. It affects at least nginx, which logs error messages such as: nginx[16652]: [crit] 16675#0: *358 SSL_read() failed (SSL: error: 4095126:SSL routines:ssl3_read_n:unexpected eof while reading) while keepalive, client: , server: [::]:443 So looks that nginx is effected. My question is : *Is Apache effected ? * Looks not, because till now: Apachelounge has more then a week 2.4.41 available with 1.1.1e, which is downloaded over 50.000 times and no issues reported like this. I did a few hundred test suite runs on 5 platforms for the 2.4.42 release candidate against OpenSSL 1.1.1e and noticed no special new ssl related errors. So either our tests do not detect it or httpd does not have that problem. There will be a new OpenSSL 1.1.1f release next week. Regards, Rainer
Re: OpenSSL 1.1.1e New EOF detection breaks session resumption
I know. > Op 27 mrt. 2020 om 20:18 heeft William A Rowe Jr het > volgende geschreven: > > > If you want to beat up your server in unusual ways, a good way to do this is > to > run it against https://www.ssllabs.com/ssltest/ from Qualsys with debug > logging > level throughout. I think you'll find we already sanitize all error results. > > > >> On Fri, Mar 27, 2020 at 1:24 PM Steffen wrote: >> >> A discussion started on Apachelounge about an possible issue with OpenSSL >> 1.1.1e ( https://www.apachelounge.com/viewtopic.php?p=38941#38941 ) >> >> This is the introduced new EOF in 1.1.1e : >> https://github.com/openssl/openssl/commit/db943f43a60d1b5b1277e4b5317e8f288e7a0a3a >> >> >> Discussion on OpenSSL is at https://github.com/openssl/openssl/issues/11378 >> >> I dot understand what is going on, but Daniel Stenberg (Curl) states : The >> "poorly-implemented HTTP/1.1 servers" are still out there and are being >> used. How common? Impossible to say. >> >> >> OpenSSL has a Patch with description : >> ... possible application breakage caused by a change in behavior introduced >> in 1.1.1e. It affects at least nginx, which logs error messages such as: >> nginx[16652]: [crit] 16675#0: *358 SSL_read() failed (SSL: error: >> 4095126:SSL routines:ssl3_read_n:unexpected eof while reading) while >> keepalive, client: , server: [::]:443 >> >> So looks that nginx is effected. >> >> My question is : >> Is Apache effected ? Looks not, because till now: Apachelounge has more >> then a week 2.4.41 available with 1.1.1e, which is downloaded over 50.000 >> times and no issues reported like this. >> >> Steffen
Re: OpenSSL 1.1.1e New EOF detection breaks session resumption
If you want to beat up your server in unusual ways, a good way to do this is to run it against https://www.ssllabs.com/ssltest/ from Qualsys with debug logging level throughout. I think you'll find we already sanitize all error results. On Fri, Mar 27, 2020 at 1:24 PM Steffen wrote: > > A discussion started on Apachelounge about an possible issue with OpenSSL > 1.1.1e ( https://www.apachelounge.com/viewtopic.php?p=38941#38941 ) > > This is the introduced new EOF in 1.1.1e : > https://github.com/openssl/openssl/commit/db943f43a60d1b5b1277e4b5317e8f288e7a0a3a > > > Discussion on OpenSSL is at > https://github.com/openssl/openssl/issues/11378 > > I dot understand what is going on, but Daniel Stenberg (Curl) states > : The "poorly-implemented HTTP/1.1 servers" are still out there and are > being used. How common? Impossible to say. > > > OpenSSL has a Patch with description : > ... possible application breakage caused by a change in behavior > introduced in 1.1.1e. It affects at least nginx, which logs error messages > such as: > nginx[16652]: [crit] 16675#0: *358 SSL_read() failed (SSL: error: > 4095126:SSL routines:ssl3_read_n:unexpected eof while reading) while > keepalive, client: , server: [::]:443 > > So looks that nginx is effected. > > My question is : > *Is Apache effected ? * Looks not, because till now: Apachelounge has > more then a week 2.4.41 available with 1.1.1e, which is downloaded over > 50.000 times and no issues reported like this. > > Steffen >
OpenSSL 1.1.1e New EOF detection breaks session resumption
Re: [VOTE] Release httpd-2.4.43
On Fri, Mar 27, 2020 at 12:34 PM Steffen wrote: > +1 All fine on Windows. > Your's are still the .dsp based builds, right? I can confirm also on the CMake flavor.
Re: [VOTE] Release httpd-2.4.43
On 2020-03-27 13:09, Giovanni Bechis wrote: On 3/26/20 3:50 PM, Daniel Ruggeri wrote: Hi, all; Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball as 2.4.43: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. Works fine on both Fedora 31 and OpenBSD 6.6-current. Thanks Giovanni I will need all day today to get this running on ye Solaris 10 sparc sun4u boxen with the recent OpenSSL 1.1.1d and a few other up to date bits. I should report in later today with this running. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: [VOTE] Release httpd-2.4.43
+1 All fine on Windows. Steffen > Op 26 mrt. 2020 om 15:50 heeft Daniel Ruggeri het > volgende geschreven: > > Hi, all; >Please find below the proposed release tarball and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release this > candidate tarball as 2.4.43: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > > The computed digests of the tarball up for vote are: > sha1: 15d8605b094dfe5e283cd9e90770368dd14e26f2 *httpd-2.4.43.tar.gz > sha256: 2624e92d89b20483caeffe514a7c7ba93ab13b650295ae330f01c35d5b50d87f > *httpd-2.4.43.tar.gz > sha512: > d9879b8f8ef7d94dee1024e9c25b56d963a3b072520878a88a044629ad577c109a5456791b39016bf4f6672c04bf4a0e5cfd32381211e9acdc81d4a50b359e5e > *httpd-2.4.43.tar.gz > > The SVN tag is '2.4.43' at r1875715. > > -- > Daniel Ruggeri >
Re: [VOTE] Release httpd-2.4.43
On 3/26/20 3:50 PM, Daniel Ruggeri wrote: > Hi, all; > Please find below the proposed release tarball and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release this > candidate tarball as 2.4.43: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > Works fine on both Fedora 31 and OpenBSD 6.6-current. Thanks Giovanni
Re: [VOTE] Release httpd-2.4.43
+1: o macOS 10.14.6, Xcode 11.3.1 (Event MPM): No regressions - Perl test framework o CentOS 6.10, 64bit (Event and Worker MPM): No regressions - Perl test framework o CentOS 7.7, 64bit (Event and Worker MPM): No regressions - Perl test framework > On Mar 26, 2020, at 10:50 AM, Daniel Ruggeri wrote: > > Hi, all; >Please find below the proposed release tarball and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release this > candidate tarball as 2.4.43: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > > The computed digests of the tarball up for vote are: > sha1: 15d8605b094dfe5e283cd9e90770368dd14e26f2 *httpd-2.4.43.tar.gz > sha256: 2624e92d89b20483caeffe514a7c7ba93ab13b650295ae330f01c35d5b50d87f > *httpd-2.4.43.tar.gz > sha512: > d9879b8f8ef7d94dee1024e9c25b56d963a3b072520878a88a044629ad577c109a5456791b39016bf4f6672c04bf4a0e5cfd32381211e9acdc81d4a50b359e5e > *httpd-2.4.43.tar.gz > > The SVN tag is '2.4.43' at r1875715. > > -- > Daniel Ruggeri >
Re: [VOTE] Release httpd-2.4.43
+1: It's not just good, it's good enough! All fine with mod-h2 and mod_md test suite on OSX. Thanks Daniel! Cheers, Stefan > Am 27.03.2020 um 09:43 schrieb Yann Ylavic : > > On Thu, Mar 26, 2020 at 3:50 PM Daniel Ruggeri wrote: >> >> I would like to call a VOTE over the next few days to release this >> candidate tarball as 2.4.43: > > [X] +1: It's not just good, it's good enough! > > All good on my Debian(s) 9, 10 and 11. > Tested with event, worker and prefork. > > Thanks Daniel! > > Regards, > Yann.
Re: [VOTE] Release httpd-2.4.43
On 26/03/2020 15:50, Daniel Ruggeri wrote: [X] +1: It's not just good, it's good enough! Tested on fedora31. Thanks Daniel -- Cheers Jean-Frederic
Re: svn commit: r1874775 - /httpd/httpd/trunk/test/README.travis
On Fri, Mar 27, 2020 at 11:54 AM Graham Leggett wrote: > > We need to find the reason that in a non-async case, data is being setaside, > and we need to fix it. Connection and network output filters shouldn't care about async or not, they just feed the pipe as much as possible, and setaside what they can't (up to reinstate limits). For non-async this is pipelining, let's not disable that. For non-async (though async would also benefit from it), what we need to do is make sure that each request (worth handling in httpd) gets finally EOR-ed, so that it's accounted (pipelining for non-async, or blocking for async). The bug in the current code is about ap_request_core_filter() retaining data (because core should_yield) and returning, but not getting called again (because it's not a connection filter and the core and MPMs care only about that). Whether ap_request_core_filter() should block depending on async/non-async does not matter IMHO. Regards, Yann.
Re: svn commit: r1874775 - /httpd/httpd/trunk/test/README.travis
On 26 Mar 2020, at 13:41, Joe Orton wrote: > On Thu, Mar 26, 2020 at 01:11:10AM +0200, Graham Leggett wrote: >> The question you’re asking is “why is is an async path being taken >> when AP_MPMQ_IS_ASYNC is false”. The setasides and reinstates should >> be noops in this situation. > > The "noop" path in ap_filter_setaside_brigade is when it is passed an > empty brigade, right? It’s not right, no. To understand how this works, you need to understand how the core network filter works in Apache 2.4. For the event MPM to be able to be an event MPM, there needs to be a mechanism by which buckets are not swallowed whole. Concrete example: 1TB file bucket. We cannot block forever trying to write 1TB of data to one client, starving all other clients of the opportunity to be sent data, and call ourselves event driven. So, what the core network filter does is this: - Reinstate earlier setaside data (if there was any). - Try make non-blocking writes until the OS tells us it’s going to block. - Setaside any unconsumed buckets, back off and let someone else have a go. The core network filter also handles flow control. Pipelining is a thing, so we have to limit the number of requests in the entire request. File descriptors are a thing, so we need to track how many file buckets are in the brigade. Beyond a threshold, the core filter blocks to keep things sane. The type of buckets in this case are irrelevant and always has been. They could be heap buckets with a fixed size, virtual buckets of some kind like file buckets that are a fixed size but access their data by reference, or morphing buckets with no fixed size at all, or EOR buckets that clean up a request when consumed, or an EOC bucket that cleans up a connection being consumed. Now, lets look at trunk. This was generalised so that any filter can do what the core network filter can do: - Reinstate earlier setaside data (if there was any). - Ask if the OS is going to block - this is the should_yield. If the answer is “no”, the filter writes data. If the answer is always “no”, old filter behaviour applies, the entire brigade will get written as it did, and the core will block as it did. - If should_yield says “yes” there will data left over, set the data aside, and let someone else have a go. If should_yield is always “no”, setaside will always be empty in every filter. What happens when we enter write completion? Async MPMs will keep writing empty brigades down the filter stack, until every last setaside bucket is flushed out, then we’re done and we can handle the next request when it arrives. Now let’s look at non-async MPMs: All non-async MPMs must return “no” to should_yield. This means that all data in the filters gets written, and no data gets set aside. Because no data is set aside, there is no need to send any empty brigades down the stack to coax any unwritten setaside data to go down the chain, so existing non-async MPMs work unchanged. This is what "The setasides and reinstates should be noops in this situation” means. Now let’s look at non async filters: Non async filters don't stop until their entire brigade is written, all 1TB of it. If all the filter did was counting bucket sizes, filter passes the entire lot down and steps aside, no harm done. But if the filter transformed the data, eg by compressing it, all 1TB gets eaten in one go. Oh well. Still works though. So, the bug. It looks like async filters work fine. We are seeing the non-async case not working properly. We need to find the reason that in a non-async case, data is being setaside, and we need to fix it. Regards, Graham — smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Release httpd-2.4.43
On Thu, Mar 26, 2020 at 3:50 PM Daniel Ruggeri wrote: > > I would like to call a VOTE over the next few days to release this > candidate tarball as 2.4.43: [X] +1: It's not just good, it's good enough! All good on my Debian(s) 9, 10 and 11. Tested with event, worker and prefork. Thanks Daniel! Regards, Yann.
