Re: [VOTE] Release httpd-2.4.32

[Rainer Jung]

Am 14.03.2018 um 16:10 schrieb Joe Orton:

On Wed, Mar 14, 2018 at 02:56:19PM +, Joe Orton wrote:

This looks like the failure I see when localhost resolves to both ::1
and 127.0.0.1, which happens with modern Fedora hosts:

$ grep localhost /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

The fixes are on trunk and I intend to propose for backport to 2.4 after


I should have been clear: these are purely ab bugs, fixes are:

https://svn.apache.org/r1626956 | jkaluza | 2014-09-23 08:12:54 +0100 (Tue, 23 
Sep 2014) | 3 lines
https://svn.apache.org/r1628388 | jkaluza | 2014-09-30 11:39:41 +0100 (Tue, 30 
Sep 2014) | 2 lines


Thanks for the links. I rebuild ab using these patches (the first one 
needed a small context adjustment to apply cleanly) and the failures in 
test 5 vanished plus all other failures for RHEL 7 and SLES 12.


On the older RHEL 6 and SLES11 I always got failures for test 1 and 3. 
Running it manually I saw the error text:


"open3: close(0) failed: Bad file descriptor"

So I checked the open3 perldoc page and some usage examples and adjusted 
it slightly in r1826763. At least for my platforms the test now 
succeeds. I hope I didn't break it for others.


Regards and thanks for the new tests,

Rainer

Re: A hang with mod_md renew

[Yann Ylavic]

On Wed, Mar 14, 2018 at 11:07 PM, Yann Ylavic  wrote:
> Hi Steffen,
>
> On Wed, Mar 14, 2018 at 6:55 PM, Steffen  wrote:
>>
>> See :  https://www.apachelounge.com/viewtopic.php?p=36588#36588
>
> Could we have the log messages at LogLevel trace1?

Also, what's the configuration for MDRenewWindow there?

>
> Regards,
> Yann.

Re: A hang with mod_md renew

[Yann Ylavic]

Hi Steffen,

On Wed, Mar 14, 2018 at 6:55 PM, Steffen  wrote:
>
> See :  https://www.apachelounge.com/viewtopic.php?p=36588#36588

Could we have the log messages at LogLevel trace1?

Regards,
Yann.

Re: [VOTE] Release httpd-2.4.32

[Rainer Jung]

Am 14.03.2018 um 19:59 schrieb Daniel Ruggeri:

On 2018-03-14 09:56, Joe Orton wrote:

On Wed, Mar 14, 2018 at 12:10:20PM +0100, Rainer Jung wrote:

All 280 builds succeeded.


Geez, now I feel bad just testing one build ;) Great stuff!


+1! Rainer must be a machine... or, perhaps only partially... cyborg, 
maybe?


If so, a machine using machines ...


Regardless, I always look forward to his report on votes


... which are only as good as our unit tests. So 1000 thanks to everyone 
writing them.


Regards,

Rainer

Re: A hang with mod_md renew

[Steffen]

An other report at www.apachelounge.com/viewtopic.php?p=36590#36590 



> Op 14 mrt. 2018 om 18:55 heeft Steffen  het volgende 
> geschreven:
> 
> 
> Now it is official in httpd, I report it here and not as private mail or git.
> 
> Reported at AL:
> 
> 
> 
> Yesterday was the day for the Renew of the test certificate and of course it 
> did not work again. Instead, mod_watchdog hangs in an endless loops loop and 
> writes the logfile full
> 
> But looking  at the log it looks like a loop in mod_md.
> 
> See :  https://www.apachelounge.com/viewtopic.php?p=36588#36588
> 
> 

Re: [VOTE] Release httpd-2.4.32

[Daniel Ruggeri]

On 2018-03-14 09:56, Joe Orton wrote:

On Wed, Mar 14, 2018 at 12:10:20PM +0100, Rainer Jung wrote:

All 280 builds succeeded.


Geez, now I feel bad just testing one build ;) Great stuff!


+1! Rainer must be a machine... or, perhaps only partially... cyborg, 
maybe?


Regardless, I always look forward to his report on votes


...

Regards, Joe


--
Daniel Ruggeri

A hang with mod_md renew

[Steffen]

Now it is official in httpd, I report it here and not as private mail 
or git.


Reported at AL:



Yesterday was the day for the Renew of the test certificate and of 
course it did not work again. Instead, mod_watchdog hangs in an 
endless loops loop and writes the logfile full


But looking  at the log it looks like a loop in mod_md.

See :  https://www.apachelounge.com/viewtopic.php?p=36588#36588

Re: [VOTE] Release httpd-2.4.32

[Jim Jagielski]

+1! All good

THX!

> On Mar 9, 2018, at 9:49 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.32:
> [ ] +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:
> md5: cddf45e036657ea209145169a554bbff *httpd-2.4.32.tar.gz
> sha1: fc1f26a4d302639932332ea12b40de7503f8aab0 *httpd-2.4.32.tar.gz
> sha256: 11cd0c43135ffe89706d0558abc0d19cb4a1f203e11ada52f2e1c3f790959300 
> *httpd-2.4.32.tar.gz
>  
> -- 
> Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.32

[Joe Orton]

On Wed, Mar 14, 2018 at 02:56:19PM +, Joe Orton wrote:
> This looks like the failure I see when localhost resolves to both ::1 
> and 127.0.0.1, which happens with modern Fedora hosts:
> 
> $ grep localhost /etc/hosts
> 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
> 
> The fixes are on trunk and I intend to propose for backport to 2.4 after 

I should have been clear: these are purely ab bugs, fixes are:

https://svn.apache.org/r1626956 | jkaluza | 2014-09-23 08:12:54 +0100 (Tue, 23 
Sep 2014) | 3 lines
https://svn.apache.org/r1628388 | jkaluza | 2014-09-30 11:39:41 +0100 (Tue, 30 
Sep 2014) | 2 lines

Re: [VOTE] Release httpd-2.4.32

[Joe Orton]

On Wed, Mar 14, 2018 at 12:10:20PM +0100, Rainer Jung wrote:
> All 280 builds succeeded.

Geez, now I feel bad just testing one build ;) Great stuff!

> The following test failures were seen:
> 
> a t/ab/base.t tests 1, 3 and 5 fail always on Linux
>   - # Failed test 1 in t/ab/base.t at line 29
>   - # Failed test 3 in t/ab/base.t at line 35
>   - # Failed test 5 in t/ab/base.t at line 39
>   This might be due to differences in my Perl test environment, Solaris
>   is using a cutom build 5.22.0, Linux platforms use their platform
>   perl but with custom build test modules.
>   The tests are new, so my guess is, this is not a regression but
>   something we need to fix in the test.

This looks like the failure I see when localhost resolves to both ::1 
and 127.0.0.1, which happens with modern Fedora hosts:

$ grep localhost /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

The fixes are on trunk and I intend to propose for backport to 2.4 after 
this release.  If you comment out the ::1 line in /etc/hosts it also 
works.  Might be some RES_OPTIONS env var hack you can use to over-ride 
it, I haven't tried.

Regards, Joe

Re: [VOTE] Release httpd-2.4.32

[Rainer Jung]

Am 10.03.2018 um 03:49 schrieb Daniel Ruggeri:

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.32:


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

md5: cddf45e036657ea209145169a554bbff *httpd-2.4.32.tar.gz

sha1: fc1f26a4d302639932332ea12b40de7503f8aab0 *httpd-2.4.32.tar.gz

sha256: 11cd0c43135ffe89706d0558abc0d19cb4a1f203e11ada52f2e1c3f790959300 
*httpd-2.4.32.tar.gz


+1 to release and thank for RM!

Detailed report:

- Sigs and hashes OK
- contents of tarballs identical
- contents of tag and tarballs identical
  except for expected deltas
- deps convenience tarball contains latest APR/APU 1.6.3/1.6.1

Built on

- Solaris 10 Sparc as 32 Bit Binaries
- SLES 11+12 (64 Bits)
- RHEL 6+7 (64 Bits)

For all platforms built

- with default (shared), static and explicit shared modules
- with module sets reallyall, all, most, few, none and default
- using --enable-load-all-modules
- against "included" APR/APU from deps tarball,
  plus external APR/APU 1.6.3/1.6.1 and 1.5.2/1.5.4

- using external libraries
  - expat 2.2.5
  - pcre 8.41
  - openssl 1.0.2n plus patches
  - lua 5.3.4 (compiled with LUA_COMPAT_MODULE)
  - distcache 1.5.1
  - libxml2 2.9.8
  - libnghttp2 1.31.0
  - brotli 1.0.3
  - curl 7.58.0
  - jansson 2.11

- Tool chain:
- platform gcc except on Solaris
  (gcc 7.3.0 Solaris 10, only older APR/APU 1.5.x compiled with 
older gcc 4.9.2)

- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
  - on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE,
-D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__
and -D_XPG6

All 280 builds succeeded.

- compiler warnings:

  - modules/core/mod_watchdog.c:436: warning: 'rv' may be used
uninitialized in this function
  -> only on SLES 11, warning is correct but not critical (debug log);
 not a regression

  on RHEL 6 and SLES 11 due to older GCC versions:

  - modules/md/md_json.c:31: warning: expected [error|warning|ignored] 
after '#pragma GCC diagnostic'


  - modules/md/md_json.c:45: warning: expected [error|warning|ignored] 
after '#pragma GCC diagnostic'


  due to strange jansson dependency library header files:

include/jansson.h:134:6: warning: 'json_decrefp' defined but not used 
[-Wunused-function]
include/jansson.h:180:41: warning: 'json_error_code' defined but not 
used [-Wunused-function]
include/jansson.h:228:5: warning: 'json_object_set_nocheck' defined but 
not used [-Wunused-function]
include/jansson.h:234:5: warning: 'json_object_iter_set' defined but not 
used [-Wunused-function]
include/jansson.h:249:5: warning: 'json_array_set' defined but not used 
[-Wunused-function]
include/jansson.h:261:5: warning: 'json_array_insert' defined but not 
used [-Wunused-function]


  and only on Solaris (gcc 7.3.0)

  - modules/ldap/util_ldap_cache_mgr.c:728:32: warning: format '%ld' 
expects argument of type 'long int', but argument 6 has type 'long long 
int' [-Wformat=]


  - modules/ldap/util_ldap_cache.c:111:20: warning: format '%ld' 
expects argument of type 'long int', but argument 8 has type 'long long 
int' [-Wformat=]


  - srclib/apr-util/xlate/xlate.c:120:38: warning: passing argument 2 of
'iconv' from incompatible pointer type
[-Wincompatible-pointer-types]

  - srclib/apr-util/xlate/xlate.c:343:42: warning: passing argument 2 of
'iconv' from incompatible pointer type
[-Wincompatible-pointer-types]


Tested for

- Solaris 10, SLES 11+12, RHEL 6+7
- MPMs prefork, worker, event
  - prefork skipped on Solaris due to the accept lock problem that
leads to timeouts and thus excessive testing times in the proxy
- default, shared and static module builds
- log levels info, debug and trace8
- module sets reallyall, all, most, few, none and default
  - for "reallyall" 128 modules plus MPMs, less for other module sets
- in total 2352 combinations

The following test failures were seen:

a t/ab/base.t tests 1, 3 and 5 fail always on Linux
  - # Failed test 1 in t/ab/base.t at line 29
  - # Failed test 3 in t/ab/base.t at line 35
  - # Failed test 5 in t/ab/base.t at line 39
  This might be due to differences in my Perl test environment, Solaris
  is using a cutom build 5.22.0, Linux platforms use their platform
  perl but with custom build test modules.
  The tests are new, so my guess is, this is not a regression but
  something we need to fix in the test.

b Testing fails for module set "none" due to "User" directive
  in default config:
  AH00526: Syntax error on line 30 of .../t/conf/httpd.conf:
  Invalid command 'User', perhaps misspelled or defined by a module not
  included in the server configuration
  Not a regression

c Test 59 of t/modules/include.t only and always on
  Solaris.
  Not a regression
  

[PATCH] Return HTTP 431 (Request Header Fields Too Large) for requests with large headers

[Ivan Zhakov]

Hi,

Please find patch that changes HTTPD to return HTTP 431 (Request
Header Fields Too Large) for requests with large headers. This status
code is defined by RFC 6585 [1]. Currently HTTPD returns generic HTTP
400 (Bad Request) status code for requests with large headers.

[1] https://tools.ietf.org/html/rfc6585#section-5

-- 
Ivan Zhakov
Index: include/httpd.h
===
--- include/httpd.h (revision 1801146)
+++ include/httpd.h (working copy)
@@ -567,6 +567,7 @@
 ((x) == HTTP_LENGTH_REQUIRED)   || \
 ((x) == HTTP_REQUEST_ENTITY_TOO_LARGE) || \
 ((x) == HTTP_REQUEST_URI_TOO_LARGE) || \
+((x) == 
HTTP_REQUEST_HEADER_FIELDS_TOO_LARGE) || \
 ((x) == HTTP_INTERNAL_SERVER_ERROR) || \
 ((x) == HTTP_SERVICE_UNAVAILABLE) || \
 ((x) == HTTP_NOT_IMPLEMENTED))
Index: server/protocol.c
===
--- server/protocol.c   (revision 1801146)
+++ server/protocol.c   (working copy)
@@ -915,7 +915,7 @@
 if (value == NULL || r->server->limit_req_fieldsize >= strlen(value) )
 return 1;
 
-r->status = HTTP_BAD_REQUEST;
+r->status = HTTP_REQUEST_HEADER_FIELDS_TOO_LARGE;
 apr_table_setn(r->notes, "error-notes",
"Size of a request header field exceeds server limit.");
 ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, APLOGNO(00560) "Request "
@@ -952,15 +952,12 @@
 if (APR_STATUS_IS_TIMEUP(rv)) {
 r->status = HTTP_REQUEST_TIME_OUT;
 }
-else {
-r->status = HTTP_BAD_REQUEST;
-}
-
-/* ap_rgetline returns APR_ENOSPC if it fills up the buffer before
- * finding the end-of-line.  This is only going to happen if it
- * exceeds the configured limit for a field size.
- */
-if (rv == APR_ENOSPC) {
+else if (rv == APR_ENOSPC) {
+/* ap_rgetline returns APR_ENOSPC if it fills up the buffer 
before
+ * finding the end-of-line.  This is only going to happen if it
+ * exceeds the configured limit for a field size.
+ */
+r->status = HTTP_REQUEST_HEADER_FIELDS_TOO_LARGE;
 apr_table_setn(r->notes, "error-notes",
"Size of a request header field "
"exceeds server limit.");
@@ -971,6 +968,10 @@
   (field) ? field_name_len(field) : 0,
   (field) ? field : "");
 }
+else {
+r->status = HTTP_BAD_REQUEST;
+}
+
 return;
 }
 
@@ -1020,7 +1021,7 @@
 fold_len = last_len + len + 1; /* trailing null */
 
 if (fold_len >= (apr_size_t)(r->server->limit_req_fieldsize)) {
-r->status = HTTP_BAD_REQUEST;
+r->status = HTTP_REQUEST_HEADER_FIELDS_TOO_LARGE;
 /* report what we have accumulated so far before the
  * overflow (last_field) as the field with the problem
  */
Index: t/apache/limits.t
===
--- t/apache/limits.t   (revision 1801149)
+++ t/apache/limits.t   (working copy)
@@ -36,13 +36,13 @@
 my %xrcs = ('requestline-succeed' => 200,
 'requestline-fail'=> 414,
 'fieldsize-succeed'   => 200,
-'fieldsize-fail'  => 400,
+'fieldsize-fail'  => 431,
 'fieldcount-succeed'  => 200,
 'fieldcount-fail' => 400,
 'bodysize-succeed'=> 200,
 'bodysize-fail'   => 413,
 'merged_fieldsize-succeed' => 200,
-'merged_fieldsize-fail'=> 400,
+'merged_fieldsize-fail'=> 431,
 );
 
 my $res;

Re: Vote 2.4.32 and mod_md no valid Certificate Agreement directive

[Stefan Eissing]

> Am 13.03.2018 um 21:43 schrieb William A Rowe Jr :
> 
>> On Mon, Mar 12, 2018 at 6:23 AM, Eric Covener  wrote:
>> On Mon, Mar 12, 2018 at 6:33 AM, Stefan Eissing
>>  wrote:
>>> 
 Am 12.03.2018 um 11:23 schrieb Daniel Gruno :
 
 Would it be possible to just have a link that always points to the
 _current_ agreement, much like our docs have a /current/ directory that
 always fetches you the current 2.4 docs?
>>> 
>>> More a question for Let's Encrypt than us. Legally, that would make
>>> the ToS agreement a bit meaningless, I assume.
>> 
>> Makes sense, and from our side we shouldn't go out of our way to
>> encourage some workflow where the agreement isn't being read.
> 
> I don't know that we want to encourage service providers to make
> their service unusable in a production headless environment, either

I would consider their service highly usable. And given their numbers and 
feedback in the security community and from users, almost all seem to agree.

Maybe you are not fully aware of how this agreement thing works and how Let‘s 
Encrypt accounts continue to work once the initial agreement has been made?

>> Maybe just some additional text in the module description, including a
>> link to https://letsencrypt.org/repository/
>> I think the "prerequisites" we have could be improved with some more
>> formatting (maybe pull it out of  and into a section, add
>> bullets, etc.
> 
> What about simplifying?
> 
> [md:warn] [pid 7232:tid 2416] (22)Invalid argument: acme problem
> urn:acme:error:malformed: Provided agreement URL
> [https://letsencrypt.org/documents/2017.11.15-LE-SA-v1.2.pdf] does not
> match current agreement URL
> [https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf]
> 
> That message could surely offer a pointer to the
> MDCertificateAgreement directive?

Good suggestion.