Re: svn commit: r1869392 - in /httpd/httpd/trunk: CHANGES modules/md/md_acme.c modules/md/md_acme_drive.c modules/md/md_curl.c modules/md/md_http.c modules/md/md_version.h modules/md/mod_md_config.c

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1869392 - in /httpd/httpd/trunk: CHANGES modules/md/md_acme.c modules/md/md_acme_drive.c modules/md/md_curl.c modules/md/md_http.c modules/md/md_version.h modules/md/mod_md_config.c

Marion & Christophe JAILLET

Le 05/11/2019 à 16:04, [hidden email] a écrit :

> Author: icing
> Date: Tue Nov  5 10:06:15 2019
> New Revision: 1869392
>
> URL: http://svn.apache.org/viewvc?rev=1869392&view=rev
> Log:
>    *) mod_md v2.2.3:
>       - Configuring MDCAChallenges replaces any previous existing challenge configuration. It
>         had been additive before which was not the intended behaviour. [@mkauf]
>       - Fixing order of ACME challenges used when nothing else configured. Code now behaves as
>         documented for `MDCAChallenges`. Fixes #156. Thanks again to @mkauf for finding this.
>       - Fixing a potential, low memory null pointer dereference [thanks to @uhliarik].
>       - Fixing an incompatibility with a change in libcurl v7.66.0 that added unwanted
>         "transfer-encoding" to POST requests. This failed in directy communication with
>         Let's Encrypt boulder server. Thanks to @mkauf for finding and fixing.
>
>
> Modified:
>      httpd/httpd/trunk/CHANGES
>      httpd/httpd/trunk/modules/md/md_acme.c
>      httpd/httpd/trunk/modules/md/md_acme_drive.c
>      httpd/httpd/trunk/modules/md/md_curl.c
>      httpd/httpd/trunk/modules/md/md_http.c
>      httpd/httpd/trunk/modules/md/md_version.h
>      httpd/httpd/trunk/modules/md/mod_md_config.c
>
> Modified: httpd/httpd/trunk/CHANGES
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1869392&r1=1869391&r2=1869392&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
> +++ httpd/httpd/trunk/CHANGES [utf-8] Tue Nov  5 10:06:15 2019
> @@ -1,5 +1,15 @@
>                                                            -*- coding: utf-8 -*-
>   Changes with Apache 2.5.1
> +
> +  *) mod_md v2.2.3:
> +     - Configuring MDCAChallenges replaces any previous existing challenge configuration. It
> +       had been additive before which was not the intended behaviour. [@mkauf]
> +     - Fixing order of ACME challenges used when nothing else configured. Code now behaves as
> +       documented for `MDCAChallenges`. Fixes #156. Thanks again to @mkauf for finding this.
> +     - Fixing a potential, low memory null pointer dereference [thanks to @uhliarik].
> +     - Fixing an incompatibility with a change in libcurl v7.66.0 that added unwanted
> +       "transfer-encoding" to POST requests. This failed in directy communication with
> +       Let's Encrypt boulder server. Thanks to @mkauf for finding and fixing. [Stefan Eissing]
>  
>     *) mod_proxy: Put mod_proxy_{connect,wstunnel} tunneling code in common in
>        proxy_util.  [Yann Ylavic]
>
> Modified: httpd/httpd/trunk/modules/md/md_acme.c
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/md/md_acme.c?rev=1869392&r1=1869391&r2=1869392&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/modules/md/md_acme.c (original)
> +++ httpd/httpd/trunk/modules/md/md_acme.c Tue Nov  5 10:06:15 2019
> @@ -402,7 +402,7 @@ static apr_status_t md_acme_req_send(md_
>       if (req->req_json) {
>           body = apr_pcalloc(req->p, sizeof(*body));
>           body->data = md_json_writep(req->req_json, req->p, MD_JSON_FMT_INDENT);
> -        if (!body->data) {
> +        if (!body) {
>               rv = APR_EINVAL; goto leave;

This revert r1869018 that I committed on trunk a few days ago.
Not sure if my fix was correct, but in r1869018 this code was changed.
Before we were checking the result of 'md_json_writep()' stored in
'data', but now the retune valued is stored in 'body->data', so updating
the check accordingly makes sense to me.

Just my 2c.


CJ