Re: svn commit: r32075 - /dev/httpd/ /release/httpd/
On 1/22/19 8:13 PM, Daniel Ruggeri wrote: On 2019-01-22 11:39, Daniel Gruno wrote: On 1/22/19 6:08 PM, Daniel Ruggeri wrote: Hi, Cristophe; Thanks for the extra eye. Fortunately, this is expected behavior. Since the announcement goes out on some future date, the date is fixed up later in the announce.sh script. Daniel, could you please make sure to add a Date: header to the announcement emails that are sent out, so we don't have to rely on the archives guessing the date? :) And, if possible, a Message-ID header as well. With regards, other Daniel. Hi, Daniel; No problem. Added in r1851853! I assume it's desirable to use the same Date and Message-ID headers for messages sent to different recipients (but with the same contents/subject/etc). This should facilitate correlating replies... but I'm not sure if it's technically "correct" to do. Our archives don't really care, as they add the mailing list ID as part of the internal message id. Generally, if it's the same email but you have multiple To: lines in it, it's fine to have the same ID.
Re: svn commit: r32075 - /dev/httpd/ /release/httpd/
On 2019-01-22 11:39, Daniel Gruno wrote: On 1/22/19 6:08 PM, Daniel Ruggeri wrote: Hi, Cristophe; Thanks for the extra eye. Fortunately, this is expected behavior. Since the announcement goes out on some future date, the date is fixed up later in the announce.sh script. Daniel, could you please make sure to add a Date: header to the announcement emails that are sent out, so we don't have to rely on the archives guessing the date? :) And, if possible, a Message-ID header as well. With regards, other Daniel. Hi, Daniel; No problem. Added in r1851853! I assume it's desirable to use the same Date and Message-ID headers for messages sent to different recipients (but with the same contents/subject/etc). This should facilitate correlating replies... but I'm not sure if it's technically "correct" to do. -- Daniel Ruggeri
Re: svn commit: r32075 - /dev/httpd/ /release/httpd/
On 1/22/19 6:08 PM, Daniel Ruggeri wrote: Hi, Cristophe; Thanks for the extra eye. Fortunately, this is expected behavior. Since the announcement goes out on some future date, the date is fixed up later in the announce.sh script. Daniel, could you please make sure to add a Date: header to the announcement emails that are sent out, so we don't have to rely on the archives guessing the date? :) And, if possible, a Message-ID header as well. With regards, other Daniel.
Re: svn commit: r32075 - /dev/httpd/ /release/httpd/
Hi, Cristophe;
Thanks for the extra eye. Fortunately, this is expected behavior.
Since the announcement goes out on some future date, the date is fixed
up later in the announce.sh script.
--
Daniel Ruggeri
On 2019-01-21 13:22, Marion & Christophe JAILLET wrote:
Fixed in r32079.
I hope I did it right.
CJ
Le 21/01/2019 à 17:48, Marion et Christophe JAILLET a écrit :
s/September/January/
in the announcement (html and txt)
CJ
Message du 21/01/19 16:03
De : drugg...@apache.org
A : c...@httpd.apache.org
Copie à :
Objet : svn commit: r32075 - /dev/httpd/ /release/httpd/
Author: druggeri
Date: Mon Jan 21 15:03:33 2019
New Revision: 32075
Log:
Push 2.4.38 up to the release directory
Added:
release/httpd/CHANGES_2.4.38
- copied unchanged from r32074, dev/httpd/CHANGES_2.4.38
release/httpd/httpd-2.4.38.tar.bz2
- copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.bz2
release/httpd/httpd-2.4.38.tar.bz2.asc
- copied unchanged from r32074,
dev/httpd/httpd-2.4.38.tar.bz2.asc
release/httpd/httpd-2.4.38.tar.bz2.md5
- copied unchanged from r32074,
dev/httpd/httpd-2.4.38.tar.bz2.md5
release/httpd/httpd-2.4.38.tar.bz2.sha1
- copied unchanged from r32074,
dev/httpd/httpd-2.4.38.tar.bz2.sha1
release/httpd/httpd-2.4.38.tar.bz2.sha256
- copied unchanged from r32074,
dev/httpd/httpd-2.4.38.tar.bz2.sha256
release/httpd/httpd-2.4.38.tar.gz
- copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.gz
release/httpd/httpd-2.4.38.tar.gz.asc
- copied unchanged from r32074,
dev/httpd/httpd-2.4.38.tar.gz.asc
release/httpd/httpd-2.4.38.tar.gz.md5
- copied unchanged from r32074,
dev/httpd/httpd-2.4.38.tar.gz.md5
release/httpd/httpd-2.4.38.tar.gz.sha1
- copied unchanged from r32074,
dev/httpd/httpd-2.4.38.tar.gz.sha1
release/httpd/httpd-2.4.38.tar.gz.sha256
- copied unchanged from r32074,
dev/httpd/httpd-2.4.38.tar.gz.sha256
Removed:
dev/httpd/CHANGES_2.4
dev/httpd/CHANGES_2.4.38
dev/httpd/httpd-2.4.38-deps.tar.bz2
dev/httpd/httpd-2.4.38-deps.tar.bz2.asc
dev/httpd/httpd-2.4.38-deps.tar.bz2.md5
dev/httpd/httpd-2.4.38-deps.tar.bz2.sha1
dev/httpd/httpd-2.4.38-deps.tar.bz2.sha256
dev/httpd/httpd-2.4.38-deps.tar.gz
dev/httpd/httpd-2.4.38-deps.tar.gz.asc
dev/httpd/httpd-2.4.38-deps.tar.gz.md5
dev/httpd/httpd-2.4.38-deps.tar.gz.sha1
dev/httpd/httpd-2.4.38-deps.tar.gz.sha256
dev/httpd/httpd-2.4.38.tar.bz2
dev/httpd/httpd-2.4.38.tar.bz2.asc
dev/httpd/httpd-2.4.38.tar.bz2.md5
dev/httpd/httpd-2.4.38.tar.bz2.sha1
dev/httpd/httpd-2.4.38.tar.bz2.sha256
dev/httpd/httpd-2.4.38.tar.gz
dev/httpd/httpd-2.4.38.tar.gz.asc
dev/httpd/httpd-2.4.38.tar.gz.md5
dev/httpd/httpd-2.4.38.tar.gz.sha1
dev/httpd/httpd-2.4.38.tar.gz.sha256
Modified:
release/httpd/Announcement2.4.html
release/httpd/Announcement2.4.txt
release/httpd/CHANGES_2.4
Modified: release/httpd/Announcement2.4.html
==
--- release/httpd/Announcement2.4.html (original)
+++ release/httpd/Announcement2.4.html Mon Jan 21 15:03:33 2019
@@ -49,15 +49,15 @@
- Apache HTTP Server 2.4.37 Released
+ Apache HTTP Server 2.4.38 Released
- October 23, 2018
+ September 21, 2018
The Apache Software Foundation and the Apache HTTP Server
Project are
pleased to announce [1]
- the release of version 2.4.37 of the Apache
+ the release of version 2.4.38 of the Apache
HTTP Server ("Apache"). This version of Apache is our latest GA
release of the new generation 2.4.x branch of Apache HTTPD and
represents fifteen years of innovation by the project, and is
@@ -69,7 +69,7 @@
encourage users of all prior versions to upgrade.
- Apache HTTP Server 2.4.37 is available for download from:
+ Apache HTTP Server 2.4.38 is available for download from:
@@ -77,7 +77,7 @@
Please see the CHANGES_2.4 [2] file, linked from the download
page, for a
- full list of changes. A condensed list, CHANGES_2.4.37 [3]
includes only
+ full list of changes. A condensed list, CHANGES_2.4.38 [4]
includes only
those changes introduced since the prior 2.4 release. A summary
of all
of the security vulnerabilities addressed in this and earlier
releases
is available:
Modified: release/httpd/Announcement2.4.txt
==
--- release/httpd/Announcement2.4.txt (original)
+++ release/httpd/Announcement2.4.txt Mon Jan 21 15:03:33 2019
@@ -1,9 +1,9 @@
- Apache HTTP Server 2.4.37 Released
+ Apache HTTP Server 2.4.38 Released
- October 23, 2018
+ September 21, 2018
The Apache Software Foundation and the Apache HTTP Server
Project
- are pleased to announce the release of version 2.4.37 of the
Apache
+ are pleased to announce the release of version 2.4.38 of the
Apache
HTTP Server ("Apache"). This version of Apache is our latest GA
release of the new generation 2.4.x branch of Apache HTTPD and
represents fifteen years of innovation by the project, and is
@@ -13,7 +13,7 @@
We consider this release to be the best
Re: [PATCH] mod_proxy: fix build without APR threads
On Tue, Jan 22, 2019 at 10:49:27AM -0600, William A Rowe Jr wrote: > On Tue, Jan 22, 2019 at 10:30 AM Stefan Sperling wrote: > > > On Tue, Jan 08, 2019 at 03:46:48PM +0100, Stefan Sperling wrote: > > > mod_proxy fails to compile when APR doesn't have thread support. > > > I don't know if this is supposed to be a supported configuration, > > > but this problem did not exist with HTTPD 2.2; it showed up in 2.4. > > > > How early in 2.4? I believe no-threads/prefork/mod_proxy had been > a supported combo during 2.4.1+ lifetime. It should be corrected. I don't know when it started. I had been lazy and kept compiling my SVN dev builds with httpd 2.2 for ages. I only switched that setup to the 2.4.x line with 2.4.37, because I finally ran into enough trouble keeping my 2.2-based setup in working condition. > mod_proxy_balancer doesn't make any sense, of course, so if it > has similar issues, those aren't a worry. I patched mod_proxy_balancer since it had compilation failures in my no-threads configuration. Are you saying mod_proxy_balancer should not be compiled in the first place if threads are disabled in APR? > > The patch below adds checks for APR_HAS_THREADS and passes test > > > builds with both threaded and non-threaded APR from APR's trunk. > > > Is this the right approach? > > > > > > I also found that the http2 module won't build without thread support. > > > > This is rather known. Early in the mod_http2 adoption, it was decided > that it would not support mod_prefork. Since it only supports threaded > MPM's, that's fine, it can be disabled for no-threads. OK, that's fine as it is then. > > > I can simply omit http2 from my SVN dev builds, for now. But mod_proxy > > > is required by mod_dav_svn for SVN's write-through proxy feature. > > > > > > Any feedback on this? Should I just commit it if I don't hear anything? > > > > You can commit what you believe is the right fix to trunk, and propose > this for backport in STATUS for 2.4 branch for others to consider, test > and collect the 3 +1's needed for backporting. Will do. Thanks!
Re: [PATCH] mod_proxy: fix build without APR threads
On Tue, Jan 22, 2019 at 10:30 AM Stefan Sperling wrote: > On Tue, Jan 08, 2019 at 03:46:48PM +0100, Stefan Sperling wrote: > > mod_proxy fails to compile when APR doesn't have thread support. > > I don't know if this is supposed to be a supported configuration, > > but this problem did not exist with HTTPD 2.2; it showed up in 2.4. > How early in 2.4? I believe no-threads/prefork/mod_proxy had been a supported combo during 2.4.1+ lifetime. It should be corrected. mod_proxy_balancer doesn't make any sense, of course, so if it has similar issues, those aren't a worry. > The patch below adds checks for APR_HAS_THREADS and passes test > > builds with both threaded and non-threaded APR from APR's trunk. > > Is this the right approach? > > > > I also found that the http2 module won't build without thread support. > This is rather known. Early in the mod_http2 adoption, it was decided that it would not support mod_prefork. Since it only supports threaded MPM's, that's fine, it can be disabled for no-threads. > > I can simply omit http2 from my SVN dev builds, for now. But mod_proxy > > is required by mod_dav_svn for SVN's write-through proxy feature. > > Any feedback on this? Should I just commit it if I don't hear anything? > You can commit what you believe is the right fix to trunk, and propose this for backport in STATUS for 2.4 branch for others to consider, test and collect the 3 +1's needed for backporting.
Re: [PATCH] mod_proxy: fix build without APR threads
On Tue, Jan 08, 2019 at 03:46:48PM +0100, Stefan Sperling wrote:
> mod_proxy fails to compile when APR doesn't have thread support.
> I don't know if this is supposed to be a supported configuration,
> but this problem did not exist with HTTPD 2.2; it showed up in 2.4.
>
> The patch below adds checks for APR_HAS_THREADS and passes test
> builds with both threaded and non-threaded APR from APR's trunk.
> Is this the right approach?
>
> I also found that the http2 module won't build without thread support.
> I can simply omit http2 from my SVN dev builds, for now. But mod_proxy
> is required by mod_dav_svn for SVN's write-through proxy feature.
Any feedback on this? Should I just commit it if I don't hear anything?
> Index: modules/proxy/mod_proxy.h
> ===
> --- modules/proxy/mod_proxy.h (revision 1850749)
> +++ modules/proxy/mod_proxy.h (working copy)
> @@ -472,7 +472,9 @@ struct proxy_worker {
> proxy_conn_pool *cp;/* Connection pool to use */
> proxy_worker_shared *s; /* Shared data */
> proxy_balancer *balancer; /* which balancer am I in? */
> +#if APR_HAS_THREADS
> apr_thread_mutex_t *tmutex; /* Thread lock for updating address cache */
> +#endif
> void*context; /* general purpose storage */
> ap_conf_vector_t *section_config; /* -section wherein defined */
> };
> @@ -528,8 +530,10 @@ struct proxy_balancer {
> proxy_hashes hash;
> apr_time_t wupdated;/* timestamp of last change to workers list
> */
> proxy_balancer_method *lbmethod;
> +#if APR_HAS_THREADS
> apr_global_mutex_t *gmutex; /* global lock for updating list of workers
> */
> apr_thread_mutex_t *tmutex; /* Thread lock for updating shm */
> +#endif
> proxy_server_conf *sconf;
> void*context;/* general purpose storage */
> proxy_balancer_shared *s;/* Shared data */
> Index: modules/proxy/mod_proxy_balancer.c
> ===
> --- modules/proxy/mod_proxy_balancer.c(revision 1850749)
> +++ modules/proxy/mod_proxy_balancer.c(working copy)
> @@ -346,6 +346,7 @@ static proxy_worker *find_best_worker(proxy_balanc
> proxy_worker *candidate = NULL;
> apr_status_t rv;
>
> +#if APR_HAS_THREADS
> if ((rv = PROXY_THREAD_LOCK(balancer)) != APR_SUCCESS) {
> ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(01163)
>"%s: Lock failed for find_best_worker()",
> @@ -352,6 +353,7 @@ static proxy_worker *find_best_worker(proxy_balanc
>balancer->s->name);
> return NULL;
> }
> +#endif
>
> candidate = (*balancer->lbmethod->finder)(balancer, r);
>
> @@ -358,11 +360,13 @@ static proxy_worker *find_best_worker(proxy_balanc
> if (candidate)
> candidate->s->elected++;
>
> +#if APR_HAS_THREADS
> if ((rv = PROXY_THREAD_UNLOCK(balancer)) != APR_SUCCESS) {
> ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(01164)
>"%s: Unlock failed for find_best_worker()",
>balancer->s->name);
> }
> +#endif
>
> if (candidate == NULL) {
> /* All the workers are in error state or disabled.
> @@ -492,11 +496,13 @@ static int proxy_balancer_pre_request(proxy_worker
> /* Step 2: Lock the LoadBalancer
> * XXX: perhaps we need the process lock here
> */
> +#if APR_HAS_THREADS
> if ((rv = PROXY_THREAD_LOCK(*balancer)) != APR_SUCCESS) {
> ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(01166)
>"%s: Lock failed for pre_request",
> (*balancer)->s->name);
> return DECLINED;
> }
> +#endif
>
> /* Step 3: force recovery */
> force_recovery(*balancer, r->server);
> @@ -557,20 +563,24 @@ static int proxy_balancer_pre_request(proxy_worker
> ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01167)
>"%s: All workers are in error state for route
> (%s)",
>(*balancer)->s->name, route);
> +#if APR_HAS_THREADS
> if ((rv = PROXY_THREAD_UNLOCK(*balancer)) != APR_SUCCESS) {
> ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(01168)
>"%s: Unlock failed for pre_request",
>(*balancer)->s->name);
> }
> +#endif
> return HTTP_SERVICE_UNAVAILABLE;
> }
> }
>
> +#if APR_HAS_THREADS
> if ((rv = PROXY_THREAD_UNLOCK(*balancer)) != APR_SUCCESS) {
> ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(01169)
>"%s: Unlock failed for pre_request",
>(*balancer)->s->name);
> }
> +#endif
> if (!*worker) {
> runtime = find_best_worker(*balancer, r);
> if (!runtime) {
> @@ -644,6 +654,7 @@ static int
Re: svn commit: r1851794 [1/37] - in /httpd/httpd/trunk/docs/manual: ./ developer/ howto/ misc/ mod/ platform/ programs/ rewrite/ ssl/ vhosts/
My fault (if this is a fault :) ).
It is part of r1851168 ("Give a little breath before the permalink") in order
to tweak the permalink I've added (on trunk only for now).
I've added a space because it looked nicer (IMHO)
Another less intrusive change was done on css in r1851167.
So, this is normal and not related to a java x issue.
The JDK version issue was (partly IMHO) fixed with FR and US changed to use
UTF-8.
I still have some issues with generated man files and with entities in
"Available Languages: en | fr | ja | blahblah", at least in my built
environment.
CJ
> Message du 22/01/19 15:27
> De : "Eric Covener"
> A : "Apache HTTP Server Development List"
> Copie à : c...@httpd.apache.org
> Objet : Re: svn commit: r1851794 [1/37] - in /httpd/httpd/trunk/docs/manual:
> ./ developer/ howto/ misc/ mod/ platform/ programs/ rewrite/ ssl/ vhosts/
>
> > Modified: httpd/httpd/trunk/docs/manual/bind.html.de
> > URL:
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/bind.html.de?rev=1851794=1851793=1851794=diff
> > ==
> > --- httpd/httpd/trunk/docs/manual/bind.html.de (original)
> > +++ httpd/httpd/trunk/docs/manual/bind.html.de Tue Jan 22 09:53:04 2019
> > @@ -46,7 +46,7 @@
> > Apache
Kommentare
> >
> >
> > -
Überblick¶
> > +
Überblick ¶
>
> I noticed my recent xform tried to do something like this too.
>
Re: svn commit: r1851794 [1/37] - in /httpd/httpd/trunk/docs/manual: ./ developer/ howto/ misc/ mod/ platform/ programs/ rewrite/ ssl/ vhosts/
Am 22.01.2019 um 15:27 schrieb Eric Covener: Modified: httpd/httpd/trunk/docs/manual/bind.html.de URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/bind.html.de?rev=1851794=1851793=1851794=diff == --- httpd/httpd/trunk/docs/manual/bind.html.de (original) +++ httpd/httpd/trunk/docs/manual/bind.html.de Tue Jan 22 09:53:04 2019 @@ -46,7 +46,7 @@ ApacheKommentare -Überblick +Überblick I noticed my recent xform tried to do something like this too. I used a recent Java 8 (1.8.0_201). It seems the change was already part of the checked in 2.4 docs, so there the commit diff was much smaller. In trunk and 2.4 I both regenerated the docs using the same Java and the commands: build.sh extraclean bootstrap modulelists metafiles \ convmap typemaps validate-xml build.sh all convmap typemaps validate-xhtml I noticed the change above but I haven't investigated the reason. Especially when I saw the 2.4 was fine, so some other committers produce the same transformations. Regards, Rainer
Re: svn commit: r1851794 [1/37] - in /httpd/httpd/trunk/docs/manual: ./ developer/ howto/ misc/ mod/ platform/ programs/ rewrite/ ssl/ vhosts/
> Modified: httpd/httpd/trunk/docs/manual/bind.html.de > URL: > http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/bind.html.de?rev=1851794=1851793=1851794=diff > == > --- httpd/httpd/trunk/docs/manual/bind.html.de (original) > +++ httpd/httpd/trunk/docs/manual/bind.html.de Tue Jan 22 09:53:04 2019 > @@ -46,7 +46,7 @@ > Apache href="#comments_section">Kommentare > /> > > -Überblick href="#overview" class="permalink"> > +Überblick href="#overview" class="permalink"> I noticed my recent xform tried to do something like this too.
Re: Apache 0-day / apache-uaf / use after free bugs
Thanks for the update, Stefan! > Am 22.01.2019 um 13:42 schrieb Stefan Sperling : > > On Tue, Jan 22, 2019 at 01:31:43PM +0100, Rainer Jung wrote: >> Here's the response we have compiled from Daniel, Stefan and others: >> >> https://bz.apache.org/bugzilla/show_bug.cgi?id=63098 > > FYI, I have disabled pool debugging in OpenBSD's port of APR. > We are now using Yann's patch to force the default allocator to > call free(3) when APR pools are cleared: > https://marc.info/?l=openbsd-ports-cvs=154815812713288=2 > > This change only affects OpenBSD -current. > I do not plan to backport a patch to the OpenBSD 6.4 release. > We have had no reports indicating that http2 was crashing on OpenBSD. > The likely reason is that nobody is actually running such a setup. > If people intend to run such a setup, they should use -current for now, > or wait until OpenBSD 6.5 is released.
Re: Apache 0-day / apache-uaf / use after free bugs
On Tue, Jan 22, 2019 at 01:31:43PM +0100, Rainer Jung wrote: > Here's the response we have compiled from Daniel, Stefan and others: > > https://bz.apache.org/bugzilla/show_bug.cgi?id=63098 FYI, I have disabled pool debugging in OpenBSD's port of APR. We are now using Yann's patch to force the default allocator to call free(3) when APR pools are cleared: https://marc.info/?l=openbsd-ports-cvs=154815812713288=2 This change only affects OpenBSD -current. I do not plan to backport a patch to the OpenBSD 6.4 release. We have had no reports indicating that http2 was crashing on OpenBSD. The likely reason is that nobody is actually running such a setup. If people intend to run such a setup, they should use -current for now, or wait until OpenBSD 6.5 is released.
Re: Apache 0-day / apache-uaf / use after free bugs
Thanks! I also wrote about the h2 related parts at https://icing.github.io/mod_h2/pool-debugging.html > Am 22.01.2019 um 13:31 schrieb Rainer Jung : > > Am 22.01.2019 um 10:33 schrieb Daniel Gruno: >> On 1/22/19 8:09 AM, Stefan Priebe - Profihost AG wrote: >>> Hi, >>> >>> in twitter and other social media channels they're talking about a >>> current apache 0 day: >>> https://twitter.com/i/web/status/1087593706444730369 >>> >>> which wasn't handled / isn't currently fixed. >>> >>> Some details are here: >>> https://github.com/hannob/apache-uaf >>> >>> If this is true there will be exploits soon. Is there anything planned? >>> Does 2.4.38 fix those issues? >>> >>> Greets, >>> Stefan >>> >> Hi Stefan, and good morning. >> I figured I should write something to calm people that might be concerned. >> I will reply in length in a while (coffee is needed first), it takes time to >> write a proper response that explains our processes and considerations with >> issues like this, especially when people start hyping the matter. Such is >> social media, I guess. >> Until then, I will say quickly that we do not at present consider this >> something you should be alarmed about. Boring elaboration to follow in a >> while when I have compiled it :) >> With regards, >> Daniel, speaking as just a normal committer. > > Here's the response we have compiled from Daniel, Stefan and others: > > https://bz.apache.org/bugzilla/show_bug.cgi?id=63098 > > Regards, > > Rainer
Re: Apache 0-day / apache-uaf / use after free bugs
Am 22.01.2019 um 10:33 schrieb Daniel Gruno: On 1/22/19 8:09 AM, Stefan Priebe - Profihost AG wrote: Hi, in twitter and other social media channels they're talking about a current apache 0 day: https://twitter.com/i/web/status/1087593706444730369 which wasn't handled / isn't currently fixed. Some details are here: https://github.com/hannob/apache-uaf If this is true there will be exploits soon. Is there anything planned? Does 2.4.38 fix those issues? Greets, Stefan Hi Stefan, and good morning. I figured I should write something to calm people that might be concerned. I will reply in length in a while (coffee is needed first), it takes time to write a proper response that explains our processes and considerations with issues like this, especially when people start hyping the matter. Such is social media, I guess. Until then, I will say quickly that we do not at present consider this something you should be alarmed about. Boring elaboration to follow in a while when I have compiled it :) With regards, Daniel, speaking as just a normal committer. Here's the response we have compiled from Daniel, Stefan and others: https://bz.apache.org/bugzilla/show_bug.cgi?id=63098 Regards, Rainer
Re: Apache 0-day / apache-uaf / use after free bugs
On 1/22/19 8:09 AM, Stefan Priebe - Profihost AG wrote: Hi, in twitter and other social media channels they're talking about a current apache 0 day: https://twitter.com/i/web/status/1087593706444730369 which wasn't handled / isn't currently fixed. Some details are here: https://github.com/hannob/apache-uaf If this is true there will be exploits soon. Is there anything planned? Does 2.4.38 fix those issues? Greets, Stefan Hi Stefan, and good morning. I figured I should write something to calm people that might be concerned. I will reply in length in a while (coffee is needed first), it takes time to write a proper response that explains our processes and considerations with issues like this, especially when people start hyping the matter. Such is social media, I guess. Until then, I will say quickly that we do not at present consider this something you should be alarmed about. Boring elaboration to follow in a while when I have compiled it :) With regards, Daniel, speaking as just a normal committer.
