Re: [VOTE] Release httpd-2.4.35

[Graham Leggett]

On 18 Sep 2018, at 02:56, Daniel Ruggeri  wrote:

>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.35:
> [ ] +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.

+1 on MacOS High Sierra, FC23.

Regards,
Graham
—

Re: svn commit: r1840563 - /httpd/httpd/branches/2.4.x/STATUS

[Luca Toscano]

Hi everybody,

Il giorno mar 11 set 2018 alle ore 09:28  ha scritto:
>
> Author: icing
> Date: Tue Sep 11 13:28:19 2018
> New Revision: 1840563
>
> URL: http://svn.apache.org/viewvc?rev=1840563=rev
> Log:
> a cautious vote
>
> Modified:
> httpd/httpd/branches/2.4.x/STATUS
>
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1840563=1840562=1840563=diff
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Tue Sep 11 13:28:19 2018
> @@ -144,6 +144,12 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>   trunk patch: http://svn.apache.org/r1832092
>   2.4.x patch: svn merge -c 1832092 ^/httpd/httpd/trunk .
>   +1: elukey
> + +0.5: icing: as I read this, the change preserves the special status of 
> headers in
> + ->err_headers_out, since swapping the tables makes former error 
> headers normal ones.
> + But it is hard to see of this was ever intentional or not. Lack of 
> regressions
> + in testing may meaning someone out there relies on the former, 
> unverified
> + behaviour. OTOH, it fixes and error you saw and added test for. So, 
> I am cautiously
> + for the change.

Any more suggestions/feedback like the following for this change? I'd
really like to know if it needs more work or if it is something non
backportable to 2.4.x :)

PS: thanks Stefan for the review!

Thanks!

Luca

Re: NOTICE: Intent to T 2.4.35 in the next few hours

[William A Rowe Jr]

On Tue, Sep 18, 2018 at 1:56 PM Ruediger Pluem  wrote:

>
> > You'll likely see issues testing against OpenSSL 1.1.1 until the
> TLSv1.3
> > merge is integrated for 2.4.x, yeah, I wouldn't worry about that.
> >
> >
> > But I think this is worth highlighting in our Announcement, that we would
> > strongly caution users to build 2.4.35 against OpenSSL 1.1.0. (And we
>
> Don't we see this issues with OpenSSL 1.1.0 as well?
>

Not that I'm aware of, these weren't changed in 1.1.0. Have been using
it for over a year without such issues. This is all the side effect of the
1.1.0 -> 1.1.1 default auth callback behavior change, IIUC.


> > could tease the forthcoming 2.4 release as building against 1.1.1/TLS
> 1.3.)
> >
> > Thoughts?
>
> Makes sense.
>

Re: NOTICE: Intent to T 2.4.35 in the next few hours

[Ruediger Pluem]

On 09/18/2018 06:19 PM, William A Rowe Jr wrote:
> On Tue, Sep 18, 2018 at 2:43 AM Joe Orton  > wrote:
> 
> On Mon, Sep 17, 2018 at 06:16:34PM -0500, Daniel Ruggeri wrote:
> >Sorry - I know it wasn't a very good report. I was just seeing if
> > anyone has experienced a similar holdup. In fact, I let it run while
> > tending to other things and came back to see it had completed (but
> > failed), so perhaps it's not hung, but rather very slow.
> >
> > I'm using Debian 9 (stretch) in a container running on a 3.16.51-3
> > kernel. OpenSSL 1.1.1 is inside as well as several other dependencies...
> > these are the "latests" that my build scripts grabbed:
> 
> You'll likely see issues testing against OpenSSL 1.1.1 until the TLSv1.3
> merge is integrated for 2.4.x, yeah, I wouldn't worry about that.
> 
> 
> But I think this is worth highlighting in our Announcement, that we would
> strongly caution users to build 2.4.35 against OpenSSL 1.1.0. (And we

Don't we see this issues with OpenSSL 1.1.0 as well?

> could tease the forthcoming 2.4 release as building against 1.1.1/TLS 1.3.)
> 
> Thoughts?

Makes sense.

Regards

Rüdiger

Re: TLSv1.3 supprt for 2.4.x?

[Stefan Eissing]

> Am 18.09.2018 um 17:03 schrieb Joe Orton :
> 
>> On Tue, Sep 18, 2018 at 04:54:58PM +0200, Yann Ylavic wrote:
>>> On Tue, Sep 18, 2018 at 4:08 PM Joe Orton  wrote:
>>> 
>>> As of r1841219 I think the tlsv1.3-for-2.4.x is ready for merging...
>> 
>> Thanks Joe for the hard work!
> 
> Thanks to Stefan for getting us most of the way!
> 

I did the easy parts. You pulled this through. Thanks!

>> Does it work for mod_proxy auth with a httpd backend, both in TLS 1.3?
>> I wonder because PHA isn't enabled on mod_proxy either, IIUC.
>> Will test but possibly you did it already.
> 
> I thinkso but I will double-check it is being tested under TLSv1.3, I 
> added this for that case specifically, IIRC because I was seeing test 
> failures without it:
> 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?view=markup=1840710#l1561
> 
> Regards, Joe

Re: NOTICE: Intent to T 2.4.35 in the next few hours

[William A Rowe Jr]

On Tue, Sep 18, 2018 at 2:43 AM Joe Orton  wrote:

> On Mon, Sep 17, 2018 at 06:16:34PM -0500, Daniel Ruggeri wrote:
> >Sorry - I know it wasn't a very good report. I was just seeing if
> > anyone has experienced a similar holdup. In fact, I let it run while
> > tending to other things and came back to see it had completed (but
> > failed), so perhaps it's not hung, but rather very slow.
> >
> > I'm using Debian 9 (stretch) in a container running on a 3.16.51-3
> > kernel. OpenSSL 1.1.1 is inside as well as several other dependencies...
> > these are the "latests" that my build scripts grabbed:
>
> You'll likely see issues testing against OpenSSL 1.1.1 until the TLSv1.3
> merge is integrated for 2.4.x, yeah, I wouldn't worry about that.


But I think this is worth highlighting in our Announcement, that we would
strongly caution users to build 2.4.35 against OpenSSL 1.1.0. (And we
could tease the forthcoming 2.4 release as building against 1.1.1/TLS 1.3.)

Thoughts?

>
>

Re: TLSv1.3 supprt for 2.4.x?

[Joe Orton]

On Tue, Sep 18, 2018 at 04:54:58PM +0200, Yann Ylavic wrote:
> On Tue, Sep 18, 2018 at 4:08 PM Joe Orton  wrote:
> >
> > As of r1841219 I think the tlsv1.3-for-2.4.x is ready for merging...
> 
> Thanks Joe for the hard work!

Thanks to Stefan for getting us most of the way!

> Does it work for mod_proxy auth with a httpd backend, both in TLS 1.3?
> I wonder because PHA isn't enabled on mod_proxy either, IIUC.
> Will test but possibly you did it already.

I think so but I will double-check it is being tested under TLSv1.3, I 
added this for that case specifically, IIRC because I was seeing test 
failures without it:

http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?view=markup=1840710#l1561

Regards, Joe

Re: TLSv1.3 supprt for 2.4.x?

[Yann Ylavic]

On Tue, Sep 18, 2018 at 4:08 PM Joe Orton  wrote:
>
> As of r1841219 I think the tlsv1.3-for-2.4.x is ready for merging...

Thanks Joe for the hard work!

>
> A BIG caveat remains around Post-Handshake Auth.  With the current Perl
> stack (including whatever adjustments for OpenSSL 1.1.1 already
> required) the failures I get with the test suite and that branch are
> significant, because PHA is NOT enabled by default client-side and a
> bunch of the tests rely on that.

Does it work for mod_proxy auth with a httpd backend, both in TLS 1.3?
I wonder because PHA isn't enabled on mod_proxy either, IIUC.
Will test but possibly you did it already.

>
> I don't understand the logic behind disabling PHA by default, and I
> think it's a serious error, but I am not optimistic that the decision
> will be reversed.

It's completely incomprehensible I guess...

Regards,
Yann.

Re: svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c include/apr_atomic.h include/arch/unix/apr_arch_atomic.h test/t

[Jim Jagielski]

Moved from httpd dev (which was moved to BCC)

> On Sep 17, 2018, at 2:54 PM, Yann Ylavic  wrote:
> 
> On Mon, Sep 17, 2018 at 5:52 PM Jim Jagielski  wrote:
>> 
>> Would like to also propose for apr-1.7...
> 
> How about 128bit? :p
> 
> There are __int128 (gcc) and _m128 (MSVC) and most 64bit intel/amd
> CPUs support cmpxchg16b.

The ‘__atomic’ builtins can be used with any integral scalar or pointer type 
that is 1, 2, 4, or 8 bytes in length. 16-byte integral types are also allowed 
if ‘__int128’ (see __int128 
) 
is supported by the architecture.

This also implies that APR create a 128bit Int type, which we don't (yet).

Bumping to support 64bit was easy and logical.. bumping to 128 requires more 
legwork and is a bit more "intrusive" ;)

+1 to the theory though.

Re: TLSv1.3 supprt for 2.4.x?

[Joe Orton]

As of r1841219 I think the tlsv1.3-for-2.4.x is ready for merging...

A BIG caveat remains around Post-Handshake Auth.  With the current Perl 
stack (including whatever adjustments for OpenSSL 1.1.1 already 
required) the failures I get with the test suite and that branch are 
significant, because PHA is NOT enabled by default client-side and a 
bunch of the tests rely on that.

I don't understand the logic behind disabling PHA by default, and I 
think it's a serious error, but I am not optimistic that the decision 
will be reversed.

So with PHA disabled client side I get:

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

Hacking the Perl stack to enable PHA by default, PoC patches here - 
http://people.apache.org/~jorton/tlsv13-pha-snafu/ - I get:

t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2)
  Failed tests:  3-4
t/ssl/ocsp.t  (Wstat: 0 Tests: 3 Failed: 1)
  Failed test:  3

which I believe are both false +ves.  I'll continue working these 
remaining failures.

Regards, Joe

Re: svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c include/apr_atomic.h include/arch/unix/apr_arch_atomic.h test/t

[Graham Leggett]

On 17 Sep 2018, at 20:54, Yann Ylavic  wrote:

> How about 128bit? :p
> 
> There are __int128 (gcc) and _m128 (MSVC) and most 64bit intel/amd
> CPUs support cmpxchg16b.
> Intrinsics work on gcc, and (eg.) _InterlockedCompareExchange128 on Windows.
> 
> This can be very useful to avoid the ABA problem when doing atomics
> with 64bit pointers.
> For instance, MPM event could benefit from that (see PR 62141)...

While we’re here we should do this, +1.

Regards,
Graham
—

RE: minor nit in mod_ssl

[Houser, Rick]

In the same vein, I’ve been running this patch on our builds to get around a 
warning for certificates not matching the hostname.  Certificates are not 
expected to match the hostname with many load balancing/uptime detection 
schemes, and this one logs a LOT when it trips on every vhost.  Perhaps this 
patch should share the same fate as decided for the TLS missing SNI issue?

--- httpd-2.4.10_backup/modules/ssl/ssl_engine_init.c   2015-09-30 
07:50:30.0 -0400
+++  httpd-2.4.10/modules/ssl/ssl_engine_init.c_new 2015-10-19 
16:13:51.716000988 -0400
@@ -1002,7 +1002,7 @@

 if (modssl_X509_match_name(ptemp, cert, (const char *)s->server_hostname,
TRUE, s) == FALSE) {
-ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, APLOGNO(01909)
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(01909)
  "%s server certificate does NOT include an ID "
  "which matches the server name", key_id);
 }


Rick Houser
Web Engineer

From: William A Rowe Jr 
Sent: Monday, September 17, 2018 16:27
To: httpd 
Subject: Re: minor nit in mod_ssl

EXTERNAL EMAIL

On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing 
mailto:stefan.eiss...@greenbytes.de>> wrote:
>
> mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when 
> strict_sni_vhost_check is enabled and a request comes in without SNI.
>
> Question: is a downgrade from ERR to INFO/DEBUG backportable or do we 
> consider this a break of compatibility?



On Mon, Sep 17, 2018 at 10:43 AM William A Rowe Jr 
mailto:wr...@rowe-clan.net>> wrote:
>
> It is entirely appropriate to turn down the volume. That's what 
> module-by-module loglevels are there for.


This is the loglevel of typical garbage request streams;

[Mon Sep 17 11:44:43.036820 2018] [core:debug] [pid 26317:tid 140199172134656] 
protocol.c(965): (20014)Internal error (specific information not available): 
[client 127.0.0.1:34974] Failed to read request header 
line (null)
[Mon Sep 17 11:44:43.036871 2018] [core:debug] [pid 26317:tid 140199172134656] 
protocol.c(1318): [client 127.0.0.1:34974] AH00567: 
request failed: error reading the headers
[Mon Sep 17 15:24:46.146311 2018] [core:debug] [pid 26413:tid 140199180527360] 
protocol.c(860): [client 127.0.0.1:35330] AH02418: HTTP 
Request Line; Unrecognized protocol 'HTTP/1.xx' (perhaps whitespace was 
injected?)

It seems that TLS missing SNI fits this same debug-level pattern of diagnostics.

Re: svn commit: r1841225 - /httpd/httpd/trunk/modules/dav/main/props.c

[Ruediger Pluem]

Pools are very tricky in mod_dav. Hence additional eyeballs are very much 
welcome here.
As I only did testing with mod_dav_fs I would be keen to know if things still 
work with Subversion.
So if someone from the Subversion guys is listening here: Having this tested 
with Subversion would be very welcome :-).

Regards

Rüdiger

On 09/18/2018 02:58 PM, rpl...@apache.org wrote:
> Author: rpluem
> Date: Tue Sep 18 12:58:57 2018
> New Revision: 1841225
> 
> URL: http://svn.apache.org/viewvc?rev=1841225=rev
> Log:
> * Doing a PROPFIND on a large collection e.g. 50.000 elements can easily
>   consume 1 GB of memory as the subrequests and propdb pools are not
>   destroyed and cleared after each element was handled.
>   Do this now. There is one case in dav_get_props where elem->priv
>   lives longer then the propdb pool. In this case allocate from r->pool.
>   Furthermore also recycle propdb's which allows to clear the propdb's
>   pools instead of destroying them and creating them again.
> 
> Modified:
> httpd/httpd/trunk/modules/dav/main/props.c
> 
> Modified: httpd/httpd/trunk/modules/dav/main/props.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/dav/main/props.c?rev=1841225=1841224=1841225=diff
> ==
> --- httpd/httpd/trunk/modules/dav/main/props.c (original)
> +++ httpd/httpd/trunk/modules/dav/main/props.c Tue Sep 18 12:58:57 2018
> @@ -524,7 +524,21 @@ DAV_DECLARE(dav_error *)dav_open_propdb(
>  apr_array_header_t * ns_xlate,
>  dav_propdb **p_propdb)
>  {
> -dav_propdb *propdb = apr_pcalloc(r->pool, sizeof(*propdb));
> +dav_propdb *propdb = NULL;
> +/*
> + * Check if we have tucked away a previous propdb and reuse it.
> + * Otherwise create a new one and tuck it away
> + */
> +apr_pool_userdata_get((void **), "propdb", r->pool);
> +if (!propdb) {
> +propdb = apr_pcalloc(r->pool, sizeof(*propdb));
> +apr_pool_userdata_setn(propdb, "propdb", NULL, r->pool);
> +apr_pool_create(>p, r->pool);
> +}
> +else {
> +/* Play safe and clear the pool of the reused probdb */
> +apr_pool_clear(propdb->p);
> +}
>  
>  *p_propdb = NULL;
>  
> @@ -537,7 +551,6 @@ DAV_DECLARE(dav_error *)dav_open_propdb(
>  #endif
>  
>  propdb->r = r;
> -apr_pool_create(>p, r->pool);
>  propdb->resource = resource;
>  propdb->ns_xlate = ns_xlate;
>  
> @@ -562,10 +575,12 @@ DAV_DECLARE(void) dav_close_propdb(dav_p
>  (*propdb->db_hooks->close)(propdb->db);
>  }
>  
> -/* Currently, mod_dav's pool usage doesn't allow clearing this pool. */
> -#if 0
> -apr_pool_destroy(propdb->p);
> -#endif
> +if (propdb->subreq) {
> +ap_destroy_sub_req(propdb->subreq);
> +propdb->subreq = NULL;
> +}
> +
> +apr_pool_clear(propdb->p);
>  }
>  
>  DAV_DECLARE(dav_get_props_result) dav_get_allprops(dav_propdb *propdb,
> @@ -815,7 +830,8 @@ DAV_DECLARE(dav_get_props_result) dav_ge
>  */
>  
>  if (elem->priv == NULL) {
> -elem->priv = apr_pcalloc(propdb->p, sizeof(*priv));
> +/* elem->priv outlives propdb->p. Hence use the request pool */
> +elem->priv = apr_pcalloc(propdb->r->pool, sizeof(*priv));
>  }
>  priv = elem->priv;
>  
> 
> 
> 

Re: NOTICE: Intent to T 2.4.35 in the next few hours

[Joe Orton]

On Mon, Sep 17, 2018 at 06:16:34PM -0500, Daniel Ruggeri wrote:
>    Sorry - I know it wasn't a very good report. I was just seeing if
> anyone has experienced a similar holdup. In fact, I let it run while
> tending to other things and came back to see it had completed (but
> failed), so perhaps it's not hung, but rather very slow.
> 
> I'm using Debian 9 (stretch) in a container running on a 3.16.51-3
> kernel. OpenSSL 1.1.1 is inside as well as several other dependencies...
> these are the "latests" that my build scripts grabbed:

You'll likely see issues testing against OpenSSL 1.1.1 until the TLSv1.3 
merge is integrated for 2.4.x, yeah, I wouldn't worry about that.

Regards, Joe