Re: [RESULT - PASS] Release httpd-2.4.48
On Tue, Jun 1, 2021 at 11:07 PM Christophe JAILLET wrote: > > 2.4.48 is live now. > > However, the mails sent on annouce@a.o and annouce@httpd.a.o seem to not > have reached their destination yet. > Maybe a moderation issue on the lists. I can see it on announce@a.o, not announce@httpd.a.o so far. > > [2]: https://httpd.apache.org/security/vulnerabilities_24.html This one also looks not up to date still. Thanks Christophe for RMing, nice work! Regards; Yann.
Re: [RESULT - PASS] Release httpd-2.4.48
This always happens, remember you must send announcement.*@a.o mail from an @a.o address. Which is extra confusing if you haven't set up the SMTP validation yet. On Tue, Jun 1, 2021 at 4:07 PM Christophe JAILLET wrote: > > Le 01/06/2021 à 03:07, William A Rowe Jr a écrit : > > Christophe, thanks for your energetic efforts to kick off the next release! > > > > I looked for the post but couldn't find it, the community is confused. > > Is this release pulled for regressions? It hasn't been communicated > > well, but the release is sitting on every mirror, since 6 to 24 hours > > after you placed it on dist. > > > > Inquiring minds would like to know, you seem to confirm this release in > > this specific post, so it appears that it has happened, even if adopting > > it is unwise. > > > > Hi, > > 2.4.48 is live now. > > However, the mails sent on annouce@a.o and annouce@httpd.a.o seem to not > have reached their destination yet. > Maybe a moderation issue on the lists. > > As you can see, there is also some security related fixes. There are > listed at [1]. > > I still need to figure out a few things with our new CVE management > mechanism. So our vulnerability listing ([2]) with some more details is > not updated yet. I hope to be able to update it in the coming days. > > Most CVE fixed in this release are rated from moderate to low impact. > Only one, CVE-2021-31618 is rated as important and could be exploited > for some DoS. > > Christophe JAILLET > > > [1]: https://downloads.apache.org/httpd/CHANGES_2.4.48 > [2]: https://httpd.apache.org/security/vulnerabilities_24.html
Re: [RESULT - PASS] Release httpd-2.4.48
Le 01/06/2021 à 03:07, William A Rowe Jr a écrit : Christophe, thanks for your energetic efforts to kick off the next release! I looked for the post but couldn't find it, the community is confused. Is this release pulled for regressions? It hasn't been communicated well, but the release is sitting on every mirror, since 6 to 24 hours after you placed it on dist. Inquiring minds would like to know, you seem to confirm this release in this specific post, so it appears that it has happened, even if adopting it is unwise. Hi, 2.4.48 is live now. However, the mails sent on annouce@a.o and annouce@httpd.a.o seem to not have reached their destination yet. Maybe a moderation issue on the lists. As you can see, there is also some security related fixes. There are listed at [1]. I still need to figure out a few things with our new CVE management mechanism. So our vulnerability listing ([2]) with some more details is not updated yet. I hope to be able to update it in the coming days. Most CVE fixed in this release are rated from moderate to low impact. Only one, CVE-2021-31618 is rated as important and could be exploited for some DoS. Christophe JAILLET [1]: https://downloads.apache.org/httpd/CHANGES_2.4.48 [2]: https://httpd.apache.org/security/vulnerabilities_24.html
Re: svn commit: r1879145 - in /httpd/httpd/trunk: include/ap_mmn.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h
Hi Jean-Frédéric, On Tue, Jun 1, 2021 at 4:50 PM jean-frederic clere wrote: > > On 24/06/2020 12:16, yla...@apache.org wrote: > > Author: ylavic > > Date: Wed Jun 24 10:16:06 2020 > > New Revision: 1879145 > > > > URL: http://svn.apache.org/viewvc?rev=1879145=rev > > Log: > > Follow up to r1879080: replace ProxyUseOriginalURI by mapping=encoded. > > > > Instead of having a separate ProxyUseOriginalURI directive to control pre_ > > vs > > normal translate stage, let's handle this at each ProxyPass level, with the > > mapping= parameter. > > Any plans to document the feature? If not, I will prepare tests and docs ;-) I forgot about this one, thanks for the reminder. I have no cycles these following days, feel free to beat me at it if you want/can, otherwise I'll have a look when time permits ;) Regards; Yann.
Re: mod_proxy / mod_ssl interworking
> Am 01.06.2021 um 18:21 schrieb jean-frederic clere : > > On 01/06/2021 16:40, Stefan Eissing wrote: >>> Am 01.06.2021 um 16:39 schrieb Stefan Eissing >>> : >>> >>> PR on trunk, for review and commenting: >>> https://github.com/apache/httpd/pull/190 >>> >>> This change makes it possible to have more than one SSL module handling >>> proxy connections. The intention is to do this in a backward compatible >>> way, like the previous ap_ssl_* changes. >>> >>> The addition of a `conn_rec->outgoing` flag, set for these connections, >>> makes it easy for any connection handling code to filter on the types of >>> connections it is interested in. >>> >>> Our test suite runs fine with these changes. >> He said while Travis is still running...optimistic as always... > > https://github.com/apache/httpd/pull/190/commits/867fa126f21575f104a1717ac49eaf1d8a558d77#diff-5506c76bad00bf136938033783d8d966bc463de54a679d3a8a390621b7a793c1R131 > > Should that be filled "automagically"? How would you advise in filling that out before I commit to trunk?
Re: mod_proxy / mod_ssl interworking
On 01/06/2021 16:40, Stefan Eissing wrote: Am 01.06.2021 um 16:39 schrieb Stefan Eissing : PR on trunk, for review and commenting: https://github.com/apache/httpd/pull/190 This change makes it possible to have more than one SSL module handling proxy connections. The intention is to do this in a backward compatible way, like the previous ap_ssl_* changes. The addition of a `conn_rec->outgoing` flag, set for these connections, makes it easy for any connection handling code to filter on the types of connections it is interested in. Our test suite runs fine with these changes. He said while Travis is still running...optimistic as always... https://github.com/apache/httpd/pull/190/commits/867fa126f21575f104a1717ac49eaf1d8a558d77#diff-5506c76bad00bf136938033783d8d966bc463de54a679d3a8a390621b7a793c1R131 Should that be filled "automagically"? -- Cheers Jean-Frederic
Re: svn commit: r1879145 - in /httpd/httpd/trunk: include/ap_mmn.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h
On 24/06/2020 12:16, yla...@apache.org wrote: Author: ylavic Date: Wed Jun 24 10:16:06 2020 New Revision: 1879145 URL: http://svn.apache.org/viewvc?rev=1879145=rev Log: Follow up to r1879080: replace ProxyUseOriginalURI by mapping=encoded. Instead of having a separate ProxyUseOriginalURI directive to control pre_ vs normal translate stage, let's handle this at each ProxyPass level, with the mapping= parameter. Any plans to document the feature? If not, I will prepare tests and docs ;-) Cheers Jean-Frederic
Re: mod_proxy / mod_ssl interworking
> Am 01.06.2021 um 16:39 schrieb Stefan Eissing : > > PR on trunk, for review and commenting: > https://github.com/apache/httpd/pull/190 > > This change makes it possible to have more than one SSL module handling proxy > connections. The intention is to do this in a backward compatible way, like > the previous ap_ssl_* changes. > > The addition of a `conn_rec->outgoing` flag, set for these connections, makes > it easy for any connection handling code to filter on the types of > connections it is interested in. > > Our test suite runs fine with these changes. He said while Travis is still running...optimistic as always...
mod_proxy / mod_ssl interworking
PR on trunk, for review and commenting: https://github.com/apache/httpd/pull/190 This change makes it possible to have more than one SSL module handling proxy connections. The intention is to do this in a backward compatible way, like the previous ap_ssl_* changes. The addition of a `conn_rec->outgoing` flag, set for these connections, makes it easy for any connection handling code to filter on the types of connections it is interested in. Our test suite runs fine with these changes. Cheers, Stefan
