Re: svn commit: r1828289 - in /apr/apr/trunk: CHANGES include/apr_reslist.h util-misc/apr_reslist.c

2018-04-04 Thread Yann Ylavic 
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

2018-04-04 Thread Eric Covener 
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=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=1828288=1828289=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=1828288=1828289=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=1828288=1828289=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(>avail_list, resource, apr_res_t, link);
+if (reslist->fifo) {
+APR_RING_INSERT_TAIL(>avail_list, resource, apr_res_t, link);
+}
+else {
+APR_RING_INSERT_HEAD(>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: svn commit: r1828289 - in /apr/apr/trunk: CHANGES include/apr_reslist.h util-misc/apr_reslist.c

2018-04-04 Thread Yann Ylavic 
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: Http2 stats into mod_systemd

2018-04-04 Thread 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?

> 
> Greets,
> Stefan
> 
> Excuse my typo sent from my mobile phone.

Re: Http2 stats into mod_systemd

2018-04-04 Thread Stefan Priebe - Profihost AG 
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

2018-04-04 Thread 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

2018-04-04 Thread Stefan Eissing 
:) 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

2018-04-04 Thread Nick Kew 
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

2018-04-04 Thread Nick Kew 
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

2018-04-04 Thread 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

2018-04-04 Thread Eric Covener 
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: TLSv1.3

2018-04-04 Thread William A Rowe Jr 
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

2018-04-04 Thread Nick Kew 
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: svn commit: r1796352

2018-04-04 Thread Eric Covener 
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: TLSv1.3

2018-04-04 Thread William A Rowe Jr 
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.
>