Fixed: apache/httpd#1492 (trunk - 9cffa48)

[Travis CI]

Build Update for apache/httpd
-

Build: #1492
Status: Fixed

Duration: 6 mins and 2 secs
Commit: 9cffa48 (trunk)
Author: Stefan Eissing
Message: refrain from handling ip address alt names in pre 1.1 openssl

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1887343 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/ff5583ba76d9...9cffa480fe2d

View the full build log and details: 
https://travis-ci.com/github/apache/httpd/builds/219366788?utm_medium=notification_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16806660_medium=notification_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: svn commit: r1887342 - /httpd/httpd/trunk/modules/md/md_crypt.c

[Yann Ylavic]

On Mon, Mar 8, 2021 at 9:15 PM  wrote:
>
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> +ip = ASN1_STRING_get_data(cval->d.iPAddress);

Looks like it's ASN1_STRING_data(), without the _get ;)

> +#else
>  ip = ASN1_STRING_get0_data(cval->d.iPAddress);
> +#endif

Cheers;
Yann.

Still Failing: apache/httpd#1491 (trunk - ff5583b)

[Travis CI]

Build Update for apache/httpd
-

Build: #1491
Status: Still Failing

Duration: 17 mins and 32 secs
Commit: ff5583b (trunk)
Author: Stefan Eissing
Message: Use ASN1_STRING_data() if openssl verison < 1.1.



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1887342 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/02a1f36ff439...ff5583ba76d9

View the full build log and details: 
https://travis-ci.com/github/apache/httpd/builds/219357165?utm_medium=notification_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16806660_medium=notification_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: [RESULT: PASS] Re: [VOTE] Release libapreq2-2.15

[Yann Ylavic]

On Mon, Mar 8, 2021 at 6:00 PM Ruediger Pluem  wrote:
>
> I would be willing to vote again with a +1 if Joe is willing to roll 2.16 
> with just that change over 2.15.

+1

Still Failing: apache/httpd#1490 (trunk - 02a1f36)

[Travis CI]

Build Update for apache/httpd
-

Build: #1490
Status: Still Failing

Duration: 15 mins and 43 secs
Commit: 02a1f36 (trunk)
Author: Stefan Eissing
Message: log tags, my nemesis

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1887340 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/e3928f2b27cc...02a1f36ff439

View the full build log and details: 
https://travis-ci.com/github/apache/httpd/builds/219354368?utm_medium=notification_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16806660_medium=notification_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: [RESULT: PASS] Re: [VOTE] Release libapreq2-2.15

[Christophe JAILLET]

Le 08/03/2021 à 18:00, Ruediger Pluem a écrit :



On 3/8/21 5:40 PM, Steve Hay wrote:

On Tue, 23 Feb 2021 at 10:20, Joe Orton  wrote:


On Mon, Feb 22, 2021 at 03:57:25PM +, Steve Hay wrote:

On Fri, 13 Nov 2020 at 16:43, Joe Orton  wrote:


Thanks all for testing, the vote has passed:

PMC votes +1: ylavic, rpluem, covener
Community +1: stevehay

(Steve, looks like we need to get you on the httpd PMC!)

and no -1 votes.

I'll promote the release & prep the announcement mail.



I think these releases normally go to Perl's CPAN as well (it is item
12 in build/RELEASE), but I don't see 2.15 here:
https://metacpan.org/release/libapreq2

Do you have perms to upload there? If not then I don't mind trying to
see if I can do it. (I've done mod_perl releases before, so it might
work ;-))





The simplest way for us to fix this is to release a 2.16 with a
corrected META.yml. I've just committed rev. 1887336 to fix the
generation of the META.yml file for our next release.




I would be willing to vote again with a +1 if Joe is willing to roll 2.16 with 
just that change over 2.15.

Regards

Rüdiger




Hi,

should a new release be done quickly, BZ 56598 and maybe BZ 52370 should 
be looked at.


It looks like easy to check and test patches.
I've not svn'ed this repo so far, I won't be able to do so in the near 
future.



Just my 2c
CJ

Broken: apache/httpd#1489 (trunk - e3928f2)

[Travis CI]

Build Update for apache/httpd
-

Build: #1489
Status: Broken

Duration: 19 mins and 11 secs
Commit: e3928f2 (trunk)
Author: Stefan Eissing
Message:   *) mod_md: v2.4.0 with improvements and bugfixes
 - MDPrivateKeys allows the specification of several types. Beside "RSA" 
plus 
 optional key lengths elliptic curves can be configured. This means you can 
 have multiple certificates for a Managed Domain with different key types.
 With ```MDPrivateKeys secp384r1 rsa2048``` you get one ECDSA  and one RSA 
 certificate and all modern client will use the shorter ECDSA, while older 
 client will get the RSA certificate.
 Many thanks to @tlhackque who pushed and helped on this.
 - Support added for MDomains consisting of a wildcard. Configuring 
 ```MDomain *.host.net``` will match all virtual hosts matching that 
pattern 
 and obtain one certificate for it (assuming you have 'dns-01' challenge 
 support configured). Addresses #239.
 - Removed support for ACMEv1 servers. The only known installation used to 
 be Let's Encrypt which has disabled that version more than a year ago for 
 new accounts.
 - Andreas Ulm () implemented the 
 ```renewing``` call to ```MDMessageCmd``` that can deny a certificate 
 renewal attempt. This is useful in clustered installations, as 
 discussed in #233).
 - New event ```challenge-setup::```, triggered when the 
 challenge data for a domain has been created. This is invoked before the 
 ACME server is told to check for it. The type is one of the ACME challenge 
 types. This is invoked for every DNS name in a MDomain.
 - The max delay for retries has been raised to daily (this is like all 
 retries jittered somewhat to avoid repeats at fixed time of day).
 - Certain error codes reported by the ACME server that indicate a problem 
 with the configured data now immediately switch to daily retries. For 
 example: if the ACME server rejects a contact email or a domain name, 
 frequent retries will most likely not solve the problem. But daily retries 
 still make sense as there might be an error at the server and 
un-supervised 
 certificate renewal is the goal. Refs #222.
 - Test case and work around for domain names > 64 octets. Fixes #227.
 When the first DNS name of an MD is longer than 63 octets, the certificate
 request will not contain a CN field, but leave it up to the CA to choose 
one.
 Currently, Lets Encrypt looks for a shorter name in the SAN list given and
 fails the request if none is found. But it is really up to the CA (and what
 browsers/libs accept here) and may change over the years. That is why
 the decision is best made at the CA.
 - Retry delays now have a random +/-[0-50]% modification applied to let 
 retries from several servers spread out more, should they have been 
 restarted at the same time of day.
 - Fixed several places where the 'badNonce' return code from an ACME 
server 
 was not handled correctly. The test server 'pebble' simulates this 
behaviour 
 by default and helps nicely in verifying this behaviour. Thanks, pebble!
 - Set the default `MDActivationDelay` to 0. This was confusing to users 
that
 new certificates were deemed not usably before a day of delay. When clocks 
are
 correct, using a new certificate right away should not pose a problem.
 - When handling ACME authorization resources, the module no longer 
requires 
 the server to return a "Location" header, as was necessary in ACMEv1. 
 Fixes #216.
 - Fixed a theoretical uninitialized read when testing for JSON error 
responses 
 from the ACME CA. Reported at 
.
 - ACME problem reports from CAs that include parameters in the 
Content-Type 
 header are handled correctly. (Previously, the problem text would not be 
 reported and retries could exist CA limits.)
 - Account Update transactions to V2 CAs now use the correct POST-AS-GET 
method.  
 Previously, an empty JSON object was sent - which apparently LE accepted, 
 but others reject.



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1887337 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/f86ff6565df3...e3928f2b27cc

View the full build log and details: 
https://travis-ci.com/github/apache/httpd/builds/219339359?utm_medium=notification_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.com/account/preferences/unsubscribe?repository=16806660_medium=notification_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification_source=email.
Or configure specific recipients for 

Re: [RESULT: PASS] Re: [VOTE] Release libapreq2-2.15

[Ruediger Pluem]

On 3/8/21 5:40 PM, Steve Hay wrote:
> On Tue, 23 Feb 2021 at 10:20, Joe Orton  wrote:
>>
>> On Mon, Feb 22, 2021 at 03:57:25PM +, Steve Hay wrote:
>>> On Fri, 13 Nov 2020 at 16:43, Joe Orton  wrote:

 Thanks all for testing, the vote has passed:

 PMC votes +1: ylavic, rpluem, covener
 Community +1: stevehay

 (Steve, looks like we need to get you on the httpd PMC!)

 and no -1 votes.

 I'll promote the release & prep the announcement mail.

>>>
>>> I think these releases normally go to Perl's CPAN as well (it is item
>>> 12 in build/RELEASE), but I don't see 2.15 here:
>>> https://metacpan.org/release/libapreq2
>>>
>>> Do you have perms to upload there? If not then I don't mind trying to
>>> see if I can do it. (I've done mod_perl releases before, so it might
>>> work ;-))
>>

> The simplest way for us to fix this is to release a 2.16 with a
> corrected META.yml. I've just committed rev. 1887336 to fix the
> generation of the META.yml file for our next release.
> 


I would be willing to vote again with a +1 if Joe is willing to roll 2.16 with 
just that change over 2.15.

Regards

Rüdiger

Re: [RESULT: PASS] Re: [VOTE] Release libapreq2-2.15

[Steve Hay]

On Tue, 23 Feb 2021 at 10:20, Joe Orton  wrote:
>
> On Mon, Feb 22, 2021 at 03:57:25PM +, Steve Hay wrote:
> > On Fri, 13 Nov 2020 at 16:43, Joe Orton  wrote:
> > >
> > > Thanks all for testing, the vote has passed:
> > >
> > > PMC votes +1: ylavic, rpluem, covener
> > > Community +1: stevehay
> > >
> > > (Steve, looks like we need to get you on the httpd PMC!)
> > >
> > > and no -1 votes.
> > >
> > > I'll promote the release & prep the announcement mail.
> > >
> >
> > I think these releases normally go to Perl's CPAN as well (it is item
> > 12 in build/RELEASE), but I don't see 2.15 here:
> > https://metacpan.org/release/libapreq2
> >
> > Do you have perms to upload there? If not then I don't mind trying to
> > see if I can do it. (I've done mod_perl releases before, so it might
> > work ;-))
>
> I have never submitted anything to CPAN before, so if you are set up to
> do it, that'd be great, please go ahead!
>

Apologies for the delay in getting back to you on this. I uploaded the
file but there have been problems getting it correctly indexed -
partly due to me initially not having the required permissions (now
resolved by the CPAN admins), but also partly due to a weakness in our
META.yml file.

The distro is now on MetaCPAN, but as you can see here many modules
are listed as UNAUTHORIZED: https://metacpan.org/release/libapreq2

The problem is that our META.yml file fails to include the "file"
attribute for each item in the "provides" list. The "file" attribute
is now a *required* attribute -- see
https://metacpan.org/pod/CPAN::Meta::Spec#file1

The file is therefore regarded as invalid and MetaCPAN constructs its
own file instead, but includes every file within the distro, many of
which are not candidates for indexing and it all goes wrong...

The simplest way for us to fix this is to release a 2.16 with a
corrected META.yml. I've just committed rev. 1887336 to fix the
generation of the META.yml file for our next release.

Is there any appetite for a quick release of 2.16 to resolve this
indexing issue?

If not then we can leave it until whenever we next naturally make a
release, and in the meantime it may be possible for the CPAN admins to
fix up the indexing temporarily, but I think it's more trouble for
them than a quick release would be for us.

Re: event.c assert failed

[Stefan Eissing]

> Am 08.03.2021 um 13:49 schrieb Yann Ylavic :
> 
> Hi Stefan,
> 
>> 
>> I see an crash and log entries:
>> 
>> [mpm_event:error] [pid 28031:tid 4595580416] (9)Bad file descriptor: 
>> AH00468: error closing socket
>> [core:crit] [pid 28031:tid 4595580416] AH00102: [Mon Mar 08 11:32:48 2021] 
>> file event.c, line 565, assertion "0" failed
>> 
>> when a client opens a connection and closes it right away, not sending 
>> anything. My tls modules sees EOF in the in filter and returns it, setting 
>> c->aborted = 1.
>> 
>> I am not sure what the failed assertion is about. Is there a double close of 
>> the socket? Seems I do handle the connection state in such a case not quite 
>> as it is expected.
> 
> Hmm, if you breakpoint on apr_socket_close(), do you see it called
> multiple times?
> (I wonder if it could be the ones in core_create_conn() if/when
> apr_socket_addr_get() fails..).

Seems to happen on server shutdown and it looks as if the socket is in 
lingering close. I try to get more info what is happening...
...
[Mon Mar 08 13:56:49.158001 2021] [tls:trace3] [pid 78522:tid 123145423650816] 
tls_filter.c(648): [client 127.0.0.1:53402] bb_dump(132): 
filter_conn_output(FLUSH EOC)
[Mon Mar 08 13:56:49.158004 2021] [tls:trace2] [pid 78522:tid 123145423650816] 
tls_filter.c(724): (53)Software caused connection abort: [client 
127.0.0.1:53402] tls_filter_conn_output: passed 0 bytes
[Mon Mar 08 13:56:49.162077 2021] [core:trace3] [pid 78521:tid 123145421504512] 
request.c(361): [client 127.0.0.1:53403] request authorized without 
authentication by access_checker_ex hook: /
[Mon Mar 08 13:56:49.273972 2021] [core:trace4] [pid 78518:tid 4427951616] 
mpm_common.c(558): mpm child 78527 (gen 0/slot 3) started
[Mon Mar 08 13:56:49.274139 2021] [mpm_event:error] [pid 78522:tid 4427951616] 
(9)Bad file descriptor: AH00468: error closing socket
[Mon Mar 08 13:56:49.274616 2021] [core:crit] [pid 78522:tid 4427951616] 
AH00102: [Mon Mar 08 12:56:49 2021] file event.c, line 565, assertion "0" failed
[Mon Mar 08 13:56:49.275632 2021] [mpm_event:debug] [pid 78527:tid 
123145420967936] event.c(2611): AH02471: start_threads: Using kqueue (wakeable)
[Mon Mar 08 13:56:49.291162 2021] [core:trace4] [pid 78518:tid 4427951616] 
mpm_common.c(558): mpm child 78520 (gen 0/slot 0) exited
[Mon Mar 08 13:56:49.291199 2021] [core:trace4] [pid 78518:tid 4427951616] 
mpm_common.c(558): mpm child 78521 (gen 0/slot 1) exited
[Mon Mar 08 13:56:49.291213 2021] [core:notice] [pid 78518:tid 4427951616] 
AH00052: child pid 78522 exit signal Abort trap (6)
[Mon Mar 08 13:56:49.291217 2021] [core:trace4] [pid 78518:tid 4427951616] 
mpm_common.c(558): mpm child 78522 (gen 0/slot 2) exited
[Mon Mar 08 13:56:49.291222 2021] [core:trace4] [pid 78518:tid 4427951616] 
mpm_common.c(558): mpm child 78527 (gen 0/slot 3) exited
[Mon Mar 08 13:56:49.291342 2021] [core:info] [pid 78518:tid 4427951616] 
AH00096: removed PID file 
/Users/sei/projects/abetterinternet/mod_tls/test/gen/apache/logs/httpd.pid 
(pid=78518)
[Mon Mar 08 13:56:49.291359 2021] [mpm_event:notice] [pid 78518:tid 4427951616] 
AH00491: caught SIGTERM, shutting down
[Mon Mar 08 13:56:49.301655 2021] [core:trace4] [pid 78518] mpm_common.c(454): 
end of generation 0

Re: event.c assert failed

[Yann Ylavic]

Hi Stefan,

>
> I see an crash and log entries:
>
> [mpm_event:error] [pid 28031:tid 4595580416] (9)Bad file descriptor: AH00468: 
> error closing socket
> [core:crit] [pid 28031:tid 4595580416] AH00102: [Mon Mar 08 11:32:48 2021] 
> file event.c, line 565, assertion "0" failed
>
> when a client opens a connection and closes it right away, not sending 
> anything. My tls modules sees EOF in the in filter and returns it, setting 
> c->aborted = 1.
>
> I am not sure what the failed assertion is about. Is there a double close of 
> the socket? Seems I do handle the connection state in such a case not quite 
> as it is expected.

Hmm, if you breakpoint on apr_socket_close(), do you see it called
multiple times?
(I wonder if it could be the ones in core_create_conn() if/when
apr_socket_addr_get() fails..).

Cheers;
Yann.

event.c assert failed

[Stefan Eissing]

Hi Yann,

I see an crash and log entries:

[mpm_event:error] [pid 28031:tid 4595580416] (9)Bad file descriptor: AH00468: 
error closing socket
[core:crit] [pid 28031:tid 4595580416] AH00102: [Mon Mar 08 11:32:48 2021] file 
event.c, line 565, assertion "0" failed

when a client opens a connection and closes it right away, not sending 
anything. My tls modules sees EOF in the in filter and returns it, setting 
c->aborted = 1.

I am not sure what the failed assertion is about. Is there a double close of 
the socket? Seems I do handle the connection state in such a case not quite as 
it is expected.

- Stefan

hcmethod_t

[jean-frederic clere]

Hi,

While looking to mod_proxy_hcheck.c, only TCP,  OPTIONS, HEAD and GET 
are supported and documented (so we are good!).


In mod_proxy.c we have additionally:
{CPING, "CPING", 0},
{PROVIDER, "PROVIDER", 0},
{EOT, NULL, 1}
The CPING is the probably the AJP CPING, but what are the 2 others? What 
is planed to have there? ;-)


--
Cheers

Jean-Frederic

Re: svn commit: r1887176 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c

[jean-frederic clere]

On 08/03/2021 08:38, Ruediger Pluem wrote:



On 3/4/21 3:00 PM, jfcl...@apache.org wrote:

Author: jfclere
Date: Thu Mar  4 14:00:45 2021
New Revision: 1887176

URL: http://svn.apache.org/viewvc?rev=1887176=rev
Log:
Add balancer_manage() to allow external module to fill workers for balancers.

Modified:
 httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c

Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c?rev=1887176=1887175=1887176=diff
==
--- httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c Thu Mar  4 14:00:45 
2021
@@ -1376,6 +1376,42 @@ static int balancer_process_balancer_wor
  }
  
  /*

+ * Process a request for balancer or worker management from another module
+ */
+static int balancer_manage(request_rec *r, apr_table_t *params)
+{
+void *sconf;
+proxy_server_conf *conf;
+proxy_balancer *bsel = NULL;
+proxy_worker *wsel = NULL;
+const char *name;
+sconf = r->server->module_config;
+conf = (proxy_server_conf *) ap_get_module_config(sconf, _module);
+
+/* Process the parameters */
+if ((name = apr_table_get(params, "b"))) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, "balancer_manage "
+  "balancer: %s", name);
+bsel = ap_proxy_get_balancer(r->pool, conf,
+apr_pstrcat(r->pool, BALANCER_PREFIX, name, NULL), 0);
+}
+
+if ((name = apr_table_get(params, "w"))) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, "balancer_manage "
+  "worker: %s", name);
+wsel = ap_proxy_get_worker(r->pool, bsel, conf, name);
+}
+if (bsel) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, "balancer_manage "
+  "balancer: %s",  bsel->s->name);
+return(balancer_process_balancer_worker(r, conf, bsel, wsel, params));
+}
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, "balancer_manage failed: "
+  "No balancer!");
+return HTTP_BAD_REQUEST;
+}
+
+/*
   * builds the page and links to configure via HTLM or XML.
   */
  static void balancer_display_page(request_rec *r, proxy_server_conf *conf,
@@ -2024,6 +2060,7 @@ static void ap_proxy_balancer_register_h
  static const char *const aszPred[] = { "mpm_winnt.c", 
"mod_slotmem_shm.c", NULL};
  static const char *const aszPred2[] = { "mod_proxy.c", NULL};
   /* manager handler */
+ap_register_provider(p, "balancer", "manager", "0", _manage);


Wouldn't it be better to create a structure in mod_proxy.h that currently has 
only one field namely a function pointer
of int balancer_manage (request_rec *, apr_table_t *). This would declare this 
as a public API and would make
it possible to extend it later if needed.
If the API is planned to be limited to just this single function wouldn't an 
optional function serve us better here?


My plans are to extent balancer_manage() by supporting more parameters, 
but the approach to create a structure of function pointers is probably 
more flexible, I will prepare a new proposal this week.




Regards

Rüdiger




--
Cheers

Jean-Frederic