Re: svn commit: r1828289 - in /apr/apr/trunk: CHANGES include/apr_reslist.h util-misc/apr_reslist.c
On Thu, Apr 5, 2018 at 2:25 AM, Yann Ylavic wrote: > On Thu, Apr 5, 2018 at 2:02 AM, Eric Covener wrote: >> Would this help the mod_proxy CLOSE_WAIT issue in BZ? > > Yes I think so (when MaxSpareThreads/Servers are too high to do their > job, for some reason, otherwise it's not an issue IMHO). > > I was also thinking of a new apr_reslist_checker_set() too, where > setting checker callback (like the current constructor and destructor) > could be used to determine whether an (about-to-be-)acquired resource > is still valid before returning it to the caller (otherwise destroy it > and return the next one). > In the mod_proxy case, the checker could be based on > ap_proxy_is_socket_connected() or (better) > ap_proxy_check_connection().. But anyway, in the best case, it'd require APR-1.7...
Re: svn commit: r1828289 - in /apr/apr/trunk: CHANGES include/apr_reslist.h util-misc/apr_reslist.c
On Thu, Apr 5, 2018 at 2:02 AM, Eric Covener wrote: > Would this help the mod_proxy CLOSE_WAIT issue in BZ? Yes I think so (when MaxSpareThreads/Servers are too high to do their job, for some reason, otherwise it's not an issue IMHO). I was also thinking of a new apr_reslist_checker_set() too, where setting checker callback (like the current constructor and destructor) could be used to determine whether an (about-to-be-)acquired resource is still valid before returning it to the caller (otherwise destroy it and return the next one). In the mod_proxy case, the checker could be based on ap_proxy_is_socket_connected() or (better) ap_proxy_check_connection()..
Fwd: svn commit: r1828289 - in /apr/apr/trunk: CHANGES include/apr_reslist.h util-misc/apr_reslist.c
Would this help the mod_proxy CLOSE_WAIT issue in BZ? -- Forwarded message -- From: Date: Tue, Apr 3, 2018 at 6:00 PM Subject: svn commit: r1828289 - in /apr/apr/trunk: CHANGES include/apr_reslist.h util-misc/apr_reslist.c To: comm...@apr.apache.org Author: ylavic Date: Tue Apr 3 22:00:10 2018 New Revision: 1828289 URL: http://svn.apache.org/viewvc?rev=1828289&view=rev Log: reslist: Add apr_reslist_fifo_set(). This allows to reuse resources in FIFO mode instead of the default LIFO mode. Modified: apr/apr/trunk/CHANGES apr/apr/trunk/include/apr_reslist.h apr/apr/trunk/util-misc/apr_reslist.c Modified: apr/apr/trunk/CHANGES URL: http://svn.apache.org/viewvc/apr/apr/trunk/CHANGES?rev=1828289&r1=1828288&r2=1828289&view=diff == --- apr/apr/trunk/CHANGES [utf-8] (original) +++ apr/apr/trunk/CHANGES [utf-8] Tue Apr 3 22:00:10 2018 @@ -1,6 +1,9 @@ -*- coding: utf-8 -*- Changes for APR 2.0.0 + *) reslist: Add apr_reslist_fifo_set() to allow for reusing resources + in FIFO mode instead of the default LIFO mode. [Yann Ylavic] + *) Add apr_pool_tag_get to retrieve the pool tag name. [Joe Orton] *) Add apr_sockaddr_zone_set, apr_sockaddr_zone_set to set and retrieve Modified: apr/apr/trunk/include/apr_reslist.h URL: http://svn.apache.org/viewvc/apr/apr/trunk/include/apr_reslist.h?rev=1828289&r1=1828288&r2=1828289&view=diff == --- apr/apr/trunk/include/apr_reslist.h (original) +++ apr/apr/trunk/include/apr_reslist.h Tue Apr 3 22:00:10 2018 @@ -134,6 +134,13 @@ APR_DECLARE(apr_status_t) apr_reslist_re */ APR_DECLARE(void) apr_reslist_timeout_set(apr_reslist_t *reslist, apr_interval_time_t timeout); +/** + * Set whether the reslist reuses resources as FIFO (First In First Out) or + * LIFO (Last In First Out). + * @param reslist The resource list. + * @param fifo Set as FIFO (non zero) or LIFO (zero). + */ +APR_DECLARE(void) apr_reslist_fifo_set(apr_reslist_t *reslist, int to); /** * Return the number of outstanding resources. Modified: apr/apr/trunk/util-misc/apr_reslist.c URL: http://svn.apache.org/viewvc/apr/apr/trunk/util-misc/apr_reslist.c?rev=1828289&r1=1828288&r2=1828289&view=diff == --- apr/apr/trunk/util-misc/apr_reslist.c (original) +++ apr/apr/trunk/util-misc/apr_reslist.c Tue Apr 3 22:00:10 2018 @@ -58,6 +58,7 @@ struct apr_reslist_t { apr_thread_mutex_t *listlock; apr_thread_cond_t *avail; #endif +int fifo; }; /** @@ -80,7 +81,12 @@ static apr_res_t *pop_resource(apr_resli */ static void push_resource(apr_reslist_t *reslist, apr_res_t *resource) { -APR_RING_INSERT_HEAD(&reslist->avail_list, resource, apr_res_t, link); +if (reslist->fifo) { +APR_RING_INSERT_TAIL(&reslist->avail_list, resource, apr_res_t, link); +} +else { +APR_RING_INSERT_HEAD(&reslist->avail_list, resource, apr_res_t, link); +} resource->freed = apr_time_now(); reslist->nidle++; } @@ -434,6 +440,11 @@ APR_DECLARE(void) apr_reslist_timeout_se reslist->timeout = timeout; } +APR_DECLARE(void) apr_reslist_fifo_set(apr_reslist_t *reslist, int to) +{ +reslist->fifo = to; +} + APR_DECLARE(apr_uint32_t) apr_reslist_acquired_count(apr_reslist_t *reslist) { apr_uint32_t count; -- Eric Covener cove...@gmail.com
Re: TLSv1.3
SSLProtocol TLSv1.2 TLSv1.3 SSLProxyProtocol TLSv1.2 TLSv1.3 should be syntactically valid, no? [Wed Apr 04 18:21:11.465896 2018] [ssl:warn] [pid 2228052:tid 140031042861312] AH02532: SSLProtocol: Protocol 'TLSv1.3' overrides already set parameter(s). Check if a +/- prefix is missing. [Wed Apr 04 18:21:11.465946 2018] [ssl:warn] [pid 2228052:tid 140031042861312] AH02532: SSLProxyProtocol: Protocol 'TLSv1.3' overrides already set parameter(s). Check if a +/- prefix is missing. TLSv1.3 should begin 'unset' if TLSv1.2 is given without modifiers. On Wed, Mar 28, 2018 at 10:49 AM, Stefan Eissing wrote: > Just added TLSv1.3 support in trunk. No fancy new early data features, just > the basic. > > Open for discussion: > - The Mozilla server-side-tls people are still thinking of what they will > recommend, see: > > https://github.com/mozilla/server-side-tls/issues/191#issuecomment-376918933 > - Turns out, cipher suites are separate from <= TLSv1.2. Since servers will > co-host 1.2 and 1.3 >for some time, we need additional config directives, I think. Added > "SSLCipherSuiteV1_3" and >am ashamed of the name. > - The current handling of TLS versions that are not supported by the *SSL > lib linked is not >super helpful. It more or less pretends that the version does not exist > (unknown protocol), >but that is far from the truth. Shall we continue that or is this an > opportunity to reconsider? > - Should we allow the configuration of TLSv1_3 ciphers, even if the linked > SSL does not support >it? This is different from SSLProtocol which of course needs to fail if it > cannot enable the >version that is explicitly configured. >I think it is ok to take it into the config, even though it never > activates. > > Cheers, > > Stefan > > PS. If a FreeBSD libressl+apache maintainer is listening here, he may try if > trunk compiles with it. I would not stop him. >
Re: svn commit: r1796352
On Wed, Apr 4, 2018 at 1:02 PM, Nick Kew wrote: > On Wed, 4 Apr 2018 10:46:31 -0400 > Eric Covener wrote: > > >> What is the correct configuration that doesn't cause htaccess to be >> visited? If it's trunk only, I think it should be an alternate config >> mechanism rather than making it incompatible with any other setting in >> htaccess. > > Anything equivalent to the "canonical" example in both the > mod_status docs and the shipped httpd-info.conf.in . > > Note that the latter also implies it can be restricted to > an access list, which is misleading if any "Require" can > be bypassed through .htaccess. > > # Allow server status reports generated by mod_status, > # with the URL of http://servername/server-status > # Change the ".example.com" to match your domain to enable. > > > SetHandler server-status > Require host .example.com > Require ip 127 > > That configuration has no bearing on whether htaccess files are visited for a request to /server-status. That's why the taint check is too aggressive in this case.
Re: svn commit: r1796352
On Wed, 4 Apr 2018 10:46:31 -0400 Eric Covener wrote: > What is the correct configuration that doesn't cause htaccess to be > visited? If it's trunk only, I think it should be an alternate config > mechanism rather than making it incompatible with any other setting in > htaccess. Anything equivalent to the "canonical" example in both the mod_status docs and the shipped httpd-info.conf.in . Note that the latter also implies it can be restricted to an access list, which is misleading if any "Require" can be bypassed through .htaccess. # Allow server status reports generated by mod_status, # with the URL of http://servername/server-status # Change the ".example.com" to match your domain to enable. SetHandler server-status Require host .example.com Require ip 127 > >> Comments? > > RewriteRule [P] in htaccess isn't anywhere near "screwed up". I disagree. .htaccess has no business enabling a user to access server resources outside his/her own directories. AllowOverride Fileinfo is a mess of largely-unrelated stuff, as pointed out by (IIRC) Jacob in the earlier discussion. -- Nick Kew
Re: TLSv1.3
Not sure if you are aware of the converse of our favorite site; https://www.ssllabs.com/ssltest/viewMyClient.html On Wed, Apr 4, 2018 at 7:52 AM, Stefan Eissing wrote: > :) I have that running for HOURS already! > > Results were from 1.1.1-pre4 > >> Am 04.04.2018 um 14:46 schrieb Rainer Jung : >> >> I don't know whether it helps, but OpenSSL release pre4 (beta 2) yesterday. >> >> Regards, >> >> Rainer >> >> Am 04.04.2018 um 13:24 schrieb Stefan Eissing: >>> Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps >>> doing TLSv1.2 >>> while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft >>> still used >>> in the releases FF. >>> Just FYI. Am 03.04.2018 um 17:09 schrieb Mario Brandt : Hi Stefan, On 3 April 2018 at 14:58, Stefan Eissing wrote: > Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. With FF open the about:config page Find security.tls.version.max set the value from 3 to 4 Cheers Mario >
Re: svn commit: r1796352
On Wed, Apr 4, 2018 at 10:16 AM, Nick Kew wrote: > Sorry, missed it at the time, but this is nonsense: > >> remove r1792169 taint checks from proxy and status modules >> >> Both of these checks are problematic without further > work. >> >> status: even a .htaccess with no SetHandler blocks the handler. > > The status handler doesn't live in the filesystem. If it's > correctly configured, the filesystem won't be visited, so > of course no .htaccess will be processed. What is the correct configuration that doesn't cause htaccess to be visited? If it's trunk only, I think it should be an alternate config mechanism rather than making it incompatible with any other setting in htaccess. > >> proxy: RewriteRule ... ... [P] in htaccess is blocked. > > As it should be: for .htaccess to run resources outside > its own directories is a long-standing design bug, and > leads to security issues. Discussed with reference to > mod_proxy and mod_status in, for example > https://mail-search.apache.org/members/private-arch/httpd-security/201701.mbox/%3c63b4f81e-f742-563c-d4e4-99c4a50a7...@gmail.com%3E > https://mail-search.apache.org/members/private-arch/httpd-security/201701.mbox/%3CCALK=yjn55j31eyfmle1bvtgy-9--9ftk2yfjzsumrlql+dk...@mail.gmail.com%3E > https://mail-search.apache.org/members/private-arch/httpd-security/201701.mbox/%3c6e96a31c-c4f8-36b8-ea94-8f77a2680...@gmail.com%3E > https://mail-search.apache.org/members/private-arch/httpd-security/201701.mbox/%3CCALK=yjnwr3cncercis4icqvs_wmj-exvddxlsntrplp5qoh...@mail.gmail.com%3E I think this one did not pass the test suite. If indirectly breaking RewriteRule [P], I think it should be preceded with doc (incl upgrading) and an explicit rejection in mod_rewrite. I understand that checks are necessary in the modules due to pulling their config from the request object, but we can't just silently set these traps and let them sit in trunk. > > Leading to the patch committed in r1792169: > >> This is for trunk. I'd be more cautious about 2.4 (or 2.2) >> because it could break screwed-up-but-not-dangerous configs >> in production by refusing unexpectedly to run. For those >> I'd suggest moving the check from proxy_handler into scheme >> handlers. >> >> Comments? RewriteRule [P] in htaccess isn't anywhere near "screwed up".
Re: svn commit: r1796352
Sorry, missed it at the time, but this is nonsense: > remove r1792169 taint checks from proxy and status modules > > Both of these checks are problematic without further work. > > status: even a .htaccess with no SetHandler blocks the handler. The status handler doesn't live in the filesystem. If it's correctly configured, the filesystem won't be visited, so of course no .htaccess will be processed. > proxy: RewriteRule ... ... [P] in htaccess is blocked. As it should be: for .htaccess to run resources outside its own directories is a long-standing design bug, and leads to security issues. Discussed with reference to mod_proxy and mod_status in, for example https://mail-search.apache.org/members/private-arch/httpd-security/201701.mbox/%3c63b4f81e-f742-563c-d4e4-99c4a50a7...@gmail.com%3E https://mail-search.apache.org/members/private-arch/httpd-security/201701.mbox/%3CCALK=yjn55j31eyfmle1bvtgy-9--9ftk2yfjzsumrlql+dk...@mail.gmail.com%3E https://mail-search.apache.org/members/private-arch/httpd-security/201701.mbox/%3c6e96a31c-c4f8-36b8-ea94-8f77a2680...@gmail.com%3E https://mail-search.apache.org/members/private-arch/httpd-security/201701.mbox/%3CCALK=yjnwr3cncercis4icqvs_wmj-exvddxlsntrplp5qoh...@mail.gmail.com%3E Leading to the patch committed in r1792169: > This is for trunk. I'd be more cautious about 2.4 (or 2.2) > because it could break screwed-up-but-not-dangerous configs > in production by refusing unexpectedly to run. For those > I'd suggest moving the check from proxy_handler into scheme > handlers. > > Comments? https://mail-search.apache.org/members/private-arch/httpd-security/201702.mbox/%3c20170208154128.69d12...@bifrost.webthing.com%3E (discussion was originally on security@, but it was suggested and the reporter agreed that it could be brought to dev@). -- Nick Kew
Re: svn commit: r1796352
Sorry, missed it at the time, but this is nonsense: > remove r1792169 taint checks from proxy and status modules > > Both of these checks are problematic without further work. > > status: even a .htaccess with no SetHandler blocks the handler. The status handler doesn't live in the filesystem. If it's correctly configured, the filesystem won't be visited, so of course no .htaccess will be processed. > proxy: RewriteRule ... ... [P] in htaccess is blocked. As it should be: for .htaccess to run resources outside its own directories is a long-standing design bug, and leads to security issues. Discussed with reference to mod_proxy and mod_status in, for example https://mail-search.apache.org/members/private-arch/httpd-security/201701.mbox/%3c63b4f81e-f742-563c-d4e4-99c4a50a7...@gmail.com%3E https://mail-search.apache.org/members/private-arch/httpd-security/201701.mbox/%3CCALK=yjn55j31eyfmle1bvtgy-9--9ftk2yfjzsumrlql+dk...@mail.gmail.com%3E https://mail-search.apache.org/members/private-arch/httpd-security/201701.mbox/%3c6e96a31c-c4f8-36b8-ea94-8f77a2680...@gmail.com%3E https://mail-search.apache.org/members/private-arch/httpd-security/201701.mbox/%3CCALK=yjnwr3cncercis4icqvs_wmj-exvddxlsntrplp5qoh...@mail.gmail.com%3E Leading to the patch committed in r1792169: > This is for trunk. I'd be more cautious about 2.4 (or 2.2) > because it could break screwed-up-but-not-dangerous configs > in production by refusing unexpectedly to run. For those > I'd suggest moving the check from proxy_handler into scheme > handlers. > > Comments? https://mail-search.apache.org/members/private-arch/httpd-security/201702.mbox/%3c20170208154128.69d12...@bifrost.webthing.com%3E (discussion was originally on security@, but it was suggested and the reporter agreed that it could be brought to dev@). -- Nick Kew
Re: TLSv1.3
:) I have that running for HOURS already! Results were from 1.1.1-pre4 > Am 04.04.2018 um 14:46 schrieb Rainer Jung : > > I don't know whether it helps, but OpenSSL release pre4 (beta 2) yesterday. > > Regards, > > Rainer > > Am 04.04.2018 um 13:24 schrieb Stefan Eissing: >> Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps doing >> TLSv1.2 >> while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft still >> used >> in the releases FF. >> Just FYI. >>> Am 03.04.2018 um 17:09 schrieb Mario Brandt : >>> >>> Hi Stefan, >>> >>> On 3 April 2018 at 14:58, Stefan Eissing >>> wrote: Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. >>> >>> With FF open the about:config page >>> >>> Find >>> security.tls.version.max >>> >>> set the value from 3 to 4 >>> >>> Cheers >>> Mario
Re: TLSv1.3
I don't know whether it helps, but OpenSSL release pre4 (beta 2) yesterday. Regards, Rainer Am 04.04.2018 um 13:24 schrieb Stefan Eissing: Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps doing TLSv1.2 while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft still used in the releases FF. Just FYI. Am 03.04.2018 um 17:09 schrieb Mario Brandt : Hi Stefan, On 3 April 2018 at 14:58, Stefan Eissing wrote: Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. With FF open the about:config page Find security.tls.version.max set the value from 3 to 4 Cheers Mario
Re: Http2 stats into mod_systemd
Am 04.04.2018 um 11:59 schrieb Stefan Eissing: > >> Am 30.03.2018 um 19:20 schrieb Stefan Priebe - Profihost AG >> : >> >> Hi Stefan, >> >> would it be possible to add some http2 stats into mod_systemd status? > > Sorry for the late reply. Just looking at the module and sd_notify() use. > > Since, the status should include data from all child processes, one would > need to use the scoreboard. And for that, h2 status information would need > to be added there, AFAIK. > > What exactly would you, as a hypothetical user, be interested in? mainly what the current status shows as well but for http/2. * h2 workers * busy h2 workers * handled connections Greets, Stefan > >> >> Greets, >> Stefan >> >> Excuse my typo sent from my mobile phone. >
Re: TLSv1.3
Thanks for the tip. Unfortunately, my FF 58.0.2 and 59.0.2 still keeps doing TLSv1.2 while the Nightly goes TLSv1.3. Perhaps a matter of the previous draft still used in the releases FF. Just FYI. > Am 03.04.2018 um 17:09 schrieb Mario Brandt : > > Hi Stefan, > > On 3 April 2018 at 14:58, Stefan Eissing wrote: >> Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. > > With FF open the about:config page > > Find > security.tls.version.max > > set the value from 3 to 4 > > Cheers > Mario
Re: Http2 stats into mod_systemd
> Am 30.03.2018 um 19:20 schrieb Stefan Priebe - Profihost AG > : > > Hi Stefan, > > would it be possible to add some http2 stats into mod_systemd status? Sorry for the late reply. Just looking at the module and sd_notify() use. Since, the status should include data from all child processes, one would need to use the scoreboard. And for that, h2 status information would need to be added there, AFAIK. What exactly would you, as a hypothetical user, be interested in? > > Greets, > Stefan > > Excuse my typo sent from my mobile phone.