Graham Leggett [Sun, 5 Jul 2020 12:55:38 +0000 (12:55 +0000)]
*) Replace apr_psprintf with apr_pstrcat where the format strings only
contain %s to improve efficiency. Leave out error messages as they
are not on a crtical code path and error message become less readable
when taking out the format specifiers.
trunk patch: http://svn.apache.org/1862270
2.4.x patch: svn merge -c 1862270 ^/httpd/httpd/trunk .
+1: minfrin, rpluem, ylavic
Easy patches: synch 2.4.x and trunk
- core: Re-introduce check for sufficient PCRE version.
- core: Fix doc string for QualifyRedirectURL
- mod_proxy: really return an error message on invalid "flusher" value.
- mod_http2: Remove extra and un-needed ""
- mod_ldap: fix a (unlikely) memory leak
- ab: fix a typo
- suexec: Report error string after failure from setgid/initgroups or setuid
- mod_session_crypto: be less specific and don't echo passphrase
- mod_proxy_html: Fix proxy_html_conf.bufsz to have correct type, as
it is used with ap_set_int_slot.
- mod_md: update duplicated APLOGNOs.
Yann Ylavic [Fri, 26 Jun 2020 10:21:19 +0000 (10:21 +0000)]
Merge r1878280 from trunk:
mod_proxy_http: don't strip EOS when spooling request body to file.
To prevent stream_reqbody() from sending the FILE and FLUSH bucket in separate
brigades, and thus apr_file_setaside() to trigger if network congestion occurs
with the backend, restore the EOS in spool_reqbody_cl() which was stripped
when spooling the request body to a file.
Until APR r1878279 is released (and installed by users), apr_file_setaside()
on a temporary file (mktemp) will simply drop the file cleanup, leaking the
fd and inode..
Yann Ylavic [Fri, 26 Jun 2020 10:18:16 +0000 (10:18 +0000)]
Merge r1879179, r1879180 from trunk:
EVP_PKEY_up_ref(): fix ref count locking type for proxy EVP pkey
When enabling client authentication for proxy (SSLProxyMachineCertificateFile),
the client certificate callback function ssl_callback_proxy_cert uses another
reference count locking type then one that is used by the caller function when
trying to free the private key afterwards by using EVP_PKEY_free.
This can lead to a race-condition on pkey->references resulting in a double
free error.
On my system, the error occurs sporadically when threaded health checking
(mod_watchdog) forces two threads competing for the client's private key.
For example, see following two backtraces of a coredump where thread 1 and
thread 15 both run into CRYPTO_free(). Actually, the private key should never
be freed during run-time nor should two threads ever enter CRYPTO_free()
concurrently.
(gdb) t 1
[Switching to thread 1 (Thread 0xb2cfbb40 (LWP 16054))]
#0 0xf7f3f329 in __kernel_vsyscall ()
(gdb) bt
#0 0xf7f3f329 in __kernel_vsyscall ()
#1 0xf7cec9e7 in raise () from /lib32/libc.so.6
#2 0xf7cedfb9 in abort () from /lib32/libc.so.6
#3 0xf7d2a14d in ?? () from /lib32/libc.so.6
#4 0xf7d2fd27 in ?? () from /lib32/libc.so.6
#5 0xf7d3047d in ?? () from /lib32/libc.so.6
#6 0x08499c70 in CRYPTO_free (str=0x93376b0) at mem.c:434
#7 0x084cc063 in EVP_PKEY_free (x=0x93376b0) at p_lib.c:406
#8 0x08463917 in ssl3_send_client_certificate (s=0xad21f070) at s3_clnt.c:3475
#9 0x0845d62c in ssl3_connect (s=0xad21f070) at s3_clnt.c:426
#10 0x08484213 in SSL_connect (s=0xad21f070) at ssl_lib.c:1008
#11 0x0846f9c8 in ssl23_get_server_hello (s=0xad21f070) at s23_clnt.c:832
#12 0x0846ea45 in ssl23_connect (s=0xad21f070) at s23_clnt.c:231
#13 0x08484213 in SSL_connect (s=0xad21f070) at ssl_lib.c:1008
#14 0x08261e73 in ssl_io_filter_handshake (filter_ctx=0xb4d3f450) at ssl_engine_io.c:1245
#15 0x08263ba6 in ssl_io_filter_output (f=0xb4d3f480, bb=0xacc079a0) at ssl_engine_io.c:1760
#16 0x080ea2c9 in ap_pass_brigade (next=0xb4d3f480, bb=0xacc079a0) at util_filter.c:590
#17 0x08263b07 in ssl_io_filter_coalesce (f=0xb4d3f468, bb=0xacc079a0) at ssl_engine_io.c:1728
#18 0x080ea2c9 in ap_pass_brigade (next=0xb4d3f468, bb=0xacc079a0) at util_filter.c:590
#19 0x08251658 in hc_send (r=0xacc069b0, out=0x8c25ec8 "GET /hcheck HTTP/1.0\r\nHost: XXX\r\n\r\n", bb=0xacc079a0) at mod_proxy_hcheck.c:664
#20 0x08251eb3 in hc_check_http (baton=0xacc068d8) at mod_proxy_hcheck.c:806
#21 0x08252653 in hc_check (thread=0x8cc6b10, b=0xacc068d8) at mod_proxy_hcheck.c:870
#22 0x08383185 in thread_pool_func (t=0x8cc6b10, param=0x8c245e0) at misc/apr_thread_pool.c:266
#23 0x083baef6 in dummy_worker (opaque=0x8cc6b10) at threadproc/unix/thread.c:142
#24 0xf7ec615f in start_thread () from /lib32/libpthread.so.0
#25 0xf7da862e in clone () from /lib32/libc.so.6
(gdb) t 15
[Switching to thread 15 (Thread 0xb44feb40 (LWP 16049))]
#0 0xf7dd90a5 in _dl_addr () from /lib32/libc.so.6
(gdb) bt
#0 0xf7dd90a5 in _dl_addr () from /lib32/libc.so.6
#1 0xf7db610c in backtrace_symbols_fd () from /lib32/libc.so.6
#2 0xf7cd89ab in ?? () from /lib32/libc.so.6
#3 0xf7d2a148 in ?? () from /lib32/libc.so.6
#4 0xf7d2fd27 in ?? () from /lib32/libc.so.6
#5 0xf7d3047d in ?? () from /lib32/libc.so.6
#6 0x08499c70 in CRYPTO_free (str=0x93376b0) at mem.c:434
#7 0x084cc063 in EVP_PKEY_free (x=0x93376b0) at p_lib.c:406
#8 0x08463917 in ssl3_send_client_certificate (s=0xacf1baa0) at s3_clnt.c:3475
#9 0x0845d62c in ssl3_connect (s=0xacf1baa0) at s3_clnt.c:426
#10 0x08484213 in SSL_connect (s=0xacf1baa0) at ssl_lib.c:1008
#11 0x0846f9c8 in ssl23_get_server_hello (s=0xacf1baa0) at s23_clnt.c:832
#12 0x0846ea45 in ssl23_connect (s=0xacf1baa0) at s23_clnt.c:231
#13 0x08484213 in SSL_connect (s=0xacf1baa0) at ssl_lib.c:1008
#14 0x08261e73 in ssl_io_filter_handshake (filter_ctx=0xb4d37430) at ssl_engine_io.c:1245
#15 0x08263ba6 in ssl_io_filter_output (f=0xb4d37460, bb=0xad101588) at ssl_engine_io.c:1760
#16 0x080ea2c9 in ap_pass_brigade (next=0xb4d37460, bb=0xad101588) at util_filter.c:590
#17 0x08263b07 in ssl_io_filter_coalesce (f=0xb4d37448, bb=0xad101588) at ssl_engine_io.c:1728
#18 0x080ea2c9 in ap_pass_brigade (next=0xb4d37448, bb=0xad101588) at util_filter.c:590
#19 0x08251658 in hc_send (r=0xad100598, out=0x8c25898 "GET /hcheck HTTP/1.0\r\nHost: XXX\r\n\r\n", bb=0xad101588) at mod_proxy_hcheck.c:664
#20 0x08251eb3 in hc_check_http (baton=0xad1004c0) at mod_proxy_hcheck.c:806
#21 0x08252653 in hc_check (thread=0x8cc6ab0, b=0xad1004c0) at mod_proxy_hcheck.c:870
#22 0x08383185 in thread_pool_func (t=0x8cc6ab0, param=0x8c245e0) at misc/apr_thread_pool.c:266
#23 0x083baef6 in dummy_worker (opaque=0x8cc6ab0) at threadproc/unix/thread.c:142
#24 0xf7ec615f in start_thread () from /lib32/libpthread.so.0
#25 0xf7da862e in clone () from /lib32/libc.so.6
Joe Orton [Thu, 25 Jun 2020 13:21:17 +0000 (13:21 +0000)]
Merge r1878993, r1879103 from trunk:
For diagnosing weird non-x86 failures, dump /etc/hosts in future runs.
Add workaround for IPv6 configuration on non-x86 hosts which
appears to fix the connection failures. Almost certainly a bug
here, not at all sure where.
Joe Orton [Wed, 17 Jun 2020 11:18:59 +0000 (11:18 +0000)]
Merge r1877250, r1878502, r1878654, r1878660, r1878663, r1878889 from trunk:
[under CTR for Travis integration]
Add gcc-10 job, drop gcc-9 config from allow_failures (seems stable again).
Use -O2 for all gcc -Werror jobs otherwise warnings triggered under e.g.
aggressive inlining are not found.
Build with LDAP support for APR 1.x.
Dump end of error_log for test run failures.
Tail more error_log for failed test suite runs in Travis.
Disable all Travis notifications for forks (hopefully).
Add Travis job which runs slapd in a container to allow testing
mod_authnz_ldap, per new test case added in r1878655.
* test/travis_Dockerfile_slapd: New dockerfile for running slapd.
Update Travis LDAP testing to use new container setup script
provided by test framework.
Ruediger Pluem [Mon, 8 Jun 2020 07:30:49 +0000 (07:30 +0000)]
Merge r1878433 from trunk:
*) mod_proxy_http2: the "ping" proxy parameter
(see <https://httpd.apache.org/docs/2.4/mod/mod_proxy.html>) is now used
when checking the liveliness of a new or reused h2 connection to the backend.
With short durations, this makes load-balancing more responsive. The module
will hold back requests until ping conditions are met, using features of the
HTTP/2 protocol alone. [Ruediger Pluem, Stefan Eissing]
Joe Orton [Thu, 23 Apr 2020 13:39:49 +0000 (13:39 +0000)]
Merge r1876869 from trunk:
systemd dependencies are only needed by mod_systemd.
They should currently not be needed by httpd directly
or any other binary. So no need to add them to
HTTPD_LIBS.
systemd dependencies are only needed by mod_systemd.
They should currently not be needed by httpd directly
or any other binary. So no need to add them to
HTTPD_LIBS.