Re: release?

[Daniel Ruggeri]

On 8/30/2021 3:53 PM, Christophe JAILLET wrote:
>
> Le 30/08/2021 à 13:53, Eric Covener a écrit :
>> On Mon, Aug 30, 2021 at 7:36 AM ste...@eissing.org
>>  wrote:
>>> In what state is our release handling? Given someone holding my
>>> hand, could I do it? Or is it better to look someone over the
>>> shoulder while he does it?
>> If there is an over-the-shoulder session I would like to tag along.  I
>> am flexible on time of day but I am GMT+4 (EDT).  I can host on webex.
>> Otherwise if you just want to struggle through it I can tag along but
>> I have no experience.
>
> I can give another try with my limited experience.
>
> I definitively would like to add a --dry-run option for all scripts so
> that they can be run for learning purpose without the fear of
> un-expected impact on svn.

FWIW, the announce.sh script which collates all the security "stuff" and
sends the announce emails drops the user to a shell to inspect/examine
what WILL happen before actually doing anything. Any non-zero return
code of that shell will abort the process. I used the heck out of that
several times :-)


>
> Existing scripts are not that easy to read at first, but are
> understanbdable and following
> http://httpd.apache.org/dev/release.html#how-to-do-a-release helps a
> lot. The scripts should also be tweaked because of the latest changes
> in several places (at least web site update (now on github) and CVE
> announcement (if any) now that part of the process is handled elsewhere).
>

+1

To my knowledge, the publishing of the site and overhaul of the new CVE
process are the things requiring updates.

-- 
Daniel Ruggeri

> The CVE announcement should be much easier, now that we have a "Send
> these Emails" on cveprocess.a.o. This should simplify part of the
> process where we were preparing some scripts to send the announcement
> emails.
>
> I've been lacking time for httpd since many weeks, but I should be
> able to RM next week if needed.
>
> CJ
>
>> Also: Anyone who has a showstopper to delay a release (even if not yet
>> proposed) please add it to 2.4.x STATUS so we can get things in order.
>>

Re: [VOTE] Release httpd-2.4.46

[Daniel Ruggeri]

Hi, Bill;
   I wondered about this myself. I agree that we allow for ambiguity
when we say an issue is fixed in 2.4.44 and 2.4.45 (which weren't
released). Perhaps we should just bump the 'fixed' version up to the
released version... but then we should also add to the 'affected'
versions the version numbers we burned during QA. That's odd, too,
because we didn't release those versions so they aren't really 'affected'.

   I could go either way... the vulnerability reporting is enough "after
work" for a release that makes it a prime candidate for processing it
with announce.sh, so I'm happy to encode whatever we consider the best
way forward into that script.

-- 
Daniel Ruggeri

On 8/7/2020 8:56 AM, William A Rowe Jr wrote:
> Following the announcement link, it isn't clear that 
>
> https://httpd.apache.org/security/vulnerabilities_24.html 
>
> fixes issues in 2.4.46.
>
> Should the fixed-in be promoted to the revision of Apache HTTP Server
> actually published (released) by the project? It almost reads like
> "fixed in
> 2.4.46-dev" (which 0-day disclosures are described as, until a release
> is actually published.)
>
> On Wed, Aug 5, 2020 at 6:32 AM Daniel Ruggeri  <mailto:dan...@bitnebula.com>> wrote:
>
> Hi, all;
>
>    With 12 binding PMC +1 votes, two additional +1 votes from the
> community, and no -1 votes, I'm pleased to report that the vote has
> PASSED to release 2.4.46. I will begin the process of pushing to the
> distribution mirrors which should enable us for a Friday
> announcement -
> a great way to wrap up the week!
>
> Here are the votes I recorded during the thread:
> PMC
> jailletc36, steffenal, elukey, jorton, jfclere, ylavic, covener,
>     gbechis, gsmith, druggeri, jblond, rjung
>
> Community
> Noel Butler, wrowe
>
> -- 
> Daniel Ruggeri
>
> On 8/1/2020 9:13 AM, Daniel Ruggeri wrote:
> > Hi, all;
> >    Third time is a charm! 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.46:
> > [ ] +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:
> > sha1: 15adb7eb3dc97e89c8a4237901a9d6887056ab98 *httpd-2.4.46.tar.gz
> > sha256:
> 44b759ce932dc090c0e75c0210b4485ebf6983466fb8ca1b446c8168e1a1aec2
> > *httpd-2.4.46.tar.gz
> > sha512:
> >
> 
> 5801c1dd0365f706a5e2365e58599b5adac674f3c66b0f39249909841e6cdf16bfdfe001fbd668f323bf7b6d14b116b5e7af49867d456336fad5e685ba020b15
> > *httpd-2.4.46.tar.gz
> >
> > The SVN tag is '2.4.46' at r1880505.
> >
>

Re: svn commit: r40863 - /dev/httpd/ /release/httpd/

[Daniel Ruggeri]

Hi, Rainer;
   Right - this file gets rewritten by the announce.sh script just before the 
notification goes out. This is done to ensure that the date is correct and to 
ensure the type of release (bug, security, enhancement) is correct. It appears 
as though the file was just changed, but really it's just because the text was 
bumped as-is from the 'dev' location to the 'dist' location.
-- 
Daniel Ruggeri

On August 5, 2020 7:23:33 AM CDT, Rainer Jung  wrote:
>Could you fix the date (September 21, 2018 sems wrong).
>
>Thanks!
>
>Rainer
>
>Am 05.08.2020 um 13:32 schrieb drugg...@apache.org:
>> Author: druggeri
>> Date: Wed Aug  5 11:32:51 2020
>> New Revision: 40863
>> 
>> Log:
>> Push 2.4.46 up to the release directory
>> 
>> Added:
>>  release/httpd/CHANGES_2.4.46
>>- copied unchanged from r40862, dev/httpd/CHANGES_2.4.46
>>  release/httpd/httpd-2.4.46.tar.bz2
>>- copied unchanged from r40862, dev/httpd/httpd-2.4.46.tar.bz2
>>  release/httpd/httpd-2.4.46.tar.bz2.asc
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.bz2.asc
>>  release/httpd/httpd-2.4.46.tar.bz2.md5
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.bz2.md5
>>  release/httpd/httpd-2.4.46.tar.bz2.sha1
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.bz2.sha1
>>  release/httpd/httpd-2.4.46.tar.bz2.sha256
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.bz2.sha256
>>  release/httpd/httpd-2.4.46.tar.bz2.sha512
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.bz2.sha512
>>  release/httpd/httpd-2.4.46.tar.gz
>>- copied unchanged from r40862, dev/httpd/httpd-2.4.46.tar.gz
>>  release/httpd/httpd-2.4.46.tar.gz.asc
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.gz.asc
>>  release/httpd/httpd-2.4.46.tar.gz.md5
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.gz.md5
>>  release/httpd/httpd-2.4.46.tar.gz.sha1
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.gz.sha1
>>  release/httpd/httpd-2.4.46.tar.gz.sha256
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.gz.sha256
>>  release/httpd/httpd-2.4.46.tar.gz.sha512
>>- copied unchanged from r40862,
>dev/httpd/httpd-2.4.46.tar.gz.sha512
>> Removed:
>>  dev/httpd/CHANGES_2.4
>>  dev/httpd/CHANGES_2.4.46
>>  dev/httpd/httpd-2.4.46-deps.tar.bz2
>>  dev/httpd/httpd-2.4.46-deps.tar.bz2.asc
>>  dev/httpd/httpd-2.4.46-deps.tar.bz2.md5
>>  dev/httpd/httpd-2.4.46-deps.tar.bz2.sha1
>>  dev/httpd/httpd-2.4.46-deps.tar.bz2.sha256
>>  dev/httpd/httpd-2.4.46-deps.tar.bz2.sha512
>>  dev/httpd/httpd-2.4.46-deps.tar.gz
>>  dev/httpd/httpd-2.4.46-deps.tar.gz.asc
>>  dev/httpd/httpd-2.4.46-deps.tar.gz.md5
>>  dev/httpd/httpd-2.4.46-deps.tar.gz.sha1
>>  dev/httpd/httpd-2.4.46-deps.tar.gz.sha256
>>  dev/httpd/httpd-2.4.46-deps.tar.gz.sha512
>>  dev/httpd/httpd-2.4.46.tar.bz2
>>  dev/httpd/httpd-2.4.46.tar.bz2.asc
>>  dev/httpd/httpd-2.4.46.tar.bz2.md5
>>  dev/httpd/httpd-2.4.46.tar.bz2.sha1
>>  dev/httpd/httpd-2.4.46.tar.bz2.sha256
>>  dev/httpd/httpd-2.4.46.tar.bz2.sha512
>>  dev/httpd/httpd-2.4.46.tar.gz
>>  dev/httpd/httpd-2.4.46.tar.gz.asc
>>  dev/httpd/httpd-2.4.46.tar.gz.md5
>>  dev/httpd/httpd-2.4.46.tar.gz.sha1
>>  dev/httpd/httpd-2.4.46.tar.gz.sha256
>>  dev/httpd/httpd-2.4.46.tar.gz.sha512
>> 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 Wed Aug  5 11:32:51 2020
>> @@ -49,27 +49,27 @@
>>   
>>   
>>   
>> -   Apache HTTP Server 2.4.43 Released
>> +   Apache HTTP Server 2.4.46 Released
>>   
>>   
>> -   April 01, 2020
>> +   September 21, 2018
>>   
>>   
>>  The Apache Software Foundation and the Apache HTTP Server
>Project are
>>  pleased to href="https://www.apache.org/dist/httpd/Announcement2.4.html;>announce
>> -   the release of version 2.4.43 of the Apache
>> +   the release of version 2.4.46 of the Apache
>

Re: [VOTE] Release httpd-2.4.46

[Daniel Ruggeri]

Hi, all;

   With 12 binding PMC +1 votes, two additional +1 votes from the
community, and no -1 votes, I'm pleased to report that the vote has
PASSED to release 2.4.46. I will begin the process of pushing to the
distribution mirrors which should enable us for a Friday announcement -
a great way to wrap up the week!

Here are the votes I recorded during the thread:
PMC
jailletc36, steffenal, elukey, jorton, jfclere, ylavic, covener,
gbechis, gsmith, druggeri, jblond, rjung

Community
Noel Butler, wrowe

-- 
Daniel Ruggeri

On 8/1/2020 9:13 AM, Daniel Ruggeri wrote:
> Hi, all;
>    Third time is a charm! 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.46:
> [ ] +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:
> sha1: 15adb7eb3dc97e89c8a4237901a9d6887056ab98 *httpd-2.4.46.tar.gz
> sha256: 44b759ce932dc090c0e75c0210b4485ebf6983466fb8ca1b446c8168e1a1aec2
> *httpd-2.4.46.tar.gz
> sha512:
> 5801c1dd0365f706a5e2365e58599b5adac674f3c66b0f39249909841e6cdf16bfdfe001fbd668f323bf7b6d14b116b5e7af49867d456336fad5e685ba020b15
> *httpd-2.4.46.tar.gz
>
> The SVN tag is '2.4.46' at r1880505.
>

Re: [VOTE] Release httpd-2.4.46

[Daniel Ruggeri]

For my own +1... tested under the following versions:

system:
  kernel:
    name: Linux
    release: 4.19.0-10-amd64
    version: #1 SMP Debian 4.19.132-1 (2020-07-24)
    machine: x86_64

  libraries:
    openssl: "1.1.1g"
    openldap: "2.4.50"
    apr: "1.7.0"
    apr-util: "1.6.1"
    iconv: "1.2.2"
    brotli: "1.0.7"
    nghttp2: "1.41.0"
    zlib: "1.2.11"
    pcre: "8.44"
    libxml2: "2.9.9"
    php: "7.4.8"
    lua: "5.3.5"
    curl: "7.71.1"

-- 
Daniel Ruggeri

On 8/1/2020 9:13 AM, Daniel Ruggeri wrote:
> Hi, all;
>    Third time is a charm! 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.46:
> [ ] +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:
> sha1: 15adb7eb3dc97e89c8a4237901a9d6887056ab98 *httpd-2.4.46.tar.gz
> sha256: 44b759ce932dc090c0e75c0210b4485ebf6983466fb8ca1b446c8168e1a1aec2
> *httpd-2.4.46.tar.gz
> sha512:
> 5801c1dd0365f706a5e2365e58599b5adac674f3c66b0f39249909841e6cdf16bfdfe001fbd668f323bf7b6d14b116b5e7af49867d456336fad5e685ba020b15
> *httpd-2.4.46.tar.gz
>
> The SVN tag is '2.4.46' at r1880505.
>

Re: svn commit: r1880502 - /httpd/httpd/branches/2.4.x/CHANGES

[Daniel Ruggeri]

Sure - I'll commit the following:
  *) mod_proxy_fcgi: Fix missing APLOGNO macro argument

Straight forward enough. Thanks for the correction.

-- 
Daniel Ruggeri

On 8/1/2020 9:14 AM, Steffen wrote:
> Not agree. Fixes APLOGNO it for all platforms.  Only I reported warnings on 
> Windows. Maybe on other platforms it is suppressed. 
>
> No credit for me, used to it. 
>
> See also my comment on an other post @dev :
>
> Below said : *) mod_proxy_fcgi: Fix build on Windows
>
> Not agree, just say what really happened. 
>
> Better :  *) mod_proxy_fcgi: Fix missing macro argument
>
> No, not a fix for build on windows only, was/is building fine. APLOGNO is 
> used on all platforms, only a list of warnings from my Windows build was 
> showing a APLOGNO warning. 
>
>
>> Op 1 aug. 2020 om 16:06 heeft drugg...@apache.org het volgende geschreven:
>>
>> Author: druggeri
>> Date: Sat Aug  1 14:06:07 2020
>> New Revision: 1880502
>>
>> URL: http://svn.apache.org/viewvc?rev=1880502=rev
>> Log:
>> Note the one change with 2.4.46 before reroll
>>
>> Modified:
>>httpd/httpd/branches/2.4.x/CHANGES
>>
>> Modified: httpd/httpd/branches/2.4.x/CHANGES
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1880502=1880501=1880502=diff
>> ==
>> --- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
>> +++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Sat Aug  1 14:06:07 2020
>> @@ -1,5 +1,7 @@
>>  -*- coding: utf-8 
>> -*-
>> Changes with Apache 2.4.46
>> +  *) mod_proxy_fcgi: Fix build warnings for Windows platform
>> + [Eric Covener, Christophe Jaillet]
>>
>> Changes with Apache 2.4.45
>>
>>
>>

[VOTE] Release httpd-2.4.46

[Daniel Ruggeri]

Hi, all;
   Third time is a charm! 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.46:
[ ] +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:
sha1: 15adb7eb3dc97e89c8a4237901a9d6887056ab98 *httpd-2.4.46.tar.gz
sha256: 44b759ce932dc090c0e75c0210b4485ebf6983466fb8ca1b446c8168e1a1aec2
*httpd-2.4.46.tar.gz
sha512:
5801c1dd0365f706a5e2365e58599b5adac674f3c66b0f39249909841e6cdf16bfdfe001fbd668f323bf7b6d14b116b5e7af49867d456336fad5e685ba020b15
*httpd-2.4.46.tar.gz

The SVN tag is '2.4.46' at r1880505.

-- 
Daniel Ruggeri

Re: Pending fixes or reroll? Was: [RESULT] [VOTE] Release httpd-2.4.45

[Daniel Ruggeri]

Agreed - thank you (everyone) for the quick rally to fix this and for
confirming we don't have other work needing to be done. I apologize for
taking almost 24 hours to ACK and get us moving again.

I've updated CHANGES and will send a VOTE shortly

-- 
Daniel Ruggeri

On 7/31/2020 1:28 PM, Rainer Jung wrote:
> Since here were lots of "good-to-go, let's roll" one note though: the
> current CHANGES does not yet a section for 2.4.46, cause normally
> APLOGNO doesn't get noted on CHANGES. In this case it might be
> something like
>
>   *) mod_proxy_fcgi: Fix build on Windows.
>
> and credits for Eric (who fixed it on trunk) oand/or Christophe, who
> backported it.
>
> Best regards,
>
> Rainer
>
> Am 31.07.2020 um 15:36 schrieb Rainer Jung:
>> Since there wasn't yet any reaction to Daniel's question: Is anybody
>> right now working on more warnings fixes for Windows?
>>
>> The most prominent one (missing APLOGNo number = missing macro
>> argument) IMHO was already fixed by Christophe in r1880438. Anything
>> else worth waiting for or are we (is Daniel) good to go for 2.4.46?
>>
>> Concerning lua I'd say the fix(es) for 5.4.0 need a bit more testing.
>>
>> Regards,
>>
>> Rainer
>>
>> Am 30.07.2020 um 22:26 schrieb Daniel Ruggeri:
>>> Hi, all;
>>>     I thank everyone for their testing and quick feedback. While we had
>>> enough votes and positive feedback, we have some easily fixable
>>> warnings
>>> which have precedence for holding up a release.
>>>
>>>     To that end, I will close this vote and declare 2.4.45 dead on
>>> the vine.
>>>
>>>     I will roll 2.4.46 when we are all buttoned up with the warnings.

[RESULT] [VOTE] Release httpd-2.4.45

[Daniel Ruggeri]

Hi, all;
   I thank everyone for their testing and quick feedback. While we had
enough votes and positive feedback, we have some easily fixable warnings
which have precedence for holding up a release.

   To that end, I will close this vote and declare 2.4.45 dead on the vine.

   I will roll 2.4.46 when we are all buttoned up with the warnings.

-- 
Daniel Ruggeri

On 7/29/2020 10:26 AM, 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.45:
> [ ] +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:
> sha1: 98d470cee244a41ac933f44428ebf10149639a8c *httpd-2.4.45.tar.gz
> sha256: 653b4f24eca6852e1b6248f6dc9a6674b647fdc4d1d4583f46bd8a6c8ee049ae
> *httpd-2.4.45.tar.gz
> sha512:
> 8b1e9c22371c75efd2466c69ed48782ddcecfe0a3ff143ca3f9cb720ea2aee56f5c323a9e3ae80cd5c44f1601b5894879af03b6b3729a8ca0555bb5193a1296a
> *httpd-2.4.45.tar.gz
>
> The SVN tag is '2.4.45' at r1880411.
>

Re: [VOTE] Release httpd-2.4.45

[Daniel Ruggeri]

On 7/30/2020 2:41 PM, William A Rowe Jr wrote:
> On Thu, Jul 30, 2020 at 10:10 AM Jim Jagielski  <mailto:j...@jagunet.com>> wrote:
>
>
> > On Jul 30, 2020, at 5:55 AM, Christophe JAILLET
>  <mailto:christophe.jail...@wanadoo.fr>> wrote:
> >
> > I wouldn't say it is a show stopper, but I thought that we had a
> travis job for that.
> > Apparently, it is on trunk only (see r1879370 which is not
> backported, maybe on purpose) 
>
> I agree that it's not a show-stopper but it is something that
> seems easy to fix and, considering that (1) we want to release the
> best possible version as we can and (2) there is quite a bit of
> time between releases, I wouldn't be opposed if the RM decided to
> skip 2.4.45 and go w/ 2.4.46.
>
>  
> Agreed. And Steffen points out there is precedence.
>

Aye - and I'd hate to appear inconsistent :-)

Version numbers are cheap - I'll re-roll when we have confirmation all
is good in the 2.4 branch.

-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.45

[Daniel Ruggeri]

For my own vote:   +1

Tested platform info follows. Same note as yesterday where lua was kept
back to 5.3 rather than 5.4.

system:
  kernel:
    name: Linux
    release: 4.19.0-9-amd64
    version: #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07)
    machine: x86_64

  libraries:
    openssl: "1.1.1g"
    openldap: "2.4.50"
    apr: "1.7.0"
    apr-util: "1.6.1"
    iconv: "1.2.2"
    brotli: "1.0.7"
    nghttp2: "1.41.0"
    zlib: "1.2.11"
    pcre: "8.44"
    libxml2: "2.9.9"
    php: "7.4.8"
    lua: "5.3.5"
    curl: "7.71.1"

-- 
Daniel Ruggeri

On 7/29/2020 10:26 AM, 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.45:
> [ ] +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:
> sha1: 98d470cee244a41ac933f44428ebf10149639a8c *httpd-2.4.45.tar.gz
> sha256: 653b4f24eca6852e1b6248f6dc9a6674b647fdc4d1d4583f46bd8a6c8ee049ae
> *httpd-2.4.45.tar.gz
> sha512:
> 8b1e9c22371c75efd2466c69ed48782ddcecfe0a3ff143ca3f9cb720ea2aee56f5c323a9e3ae80cd5c44f1601b5894879af03b6b3729a8ca0555bb5193a1296a
> *httpd-2.4.45.tar.gz
>
> The SVN tag is '2.4.45' at r1880411.
>

[VOTE] Release httpd-2.4.45

[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.45:
[ ] +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:
sha1: 98d470cee244a41ac933f44428ebf10149639a8c *httpd-2.4.45.tar.gz
sha256: 653b4f24eca6852e1b6248f6dc9a6674b647fdc4d1d4583f46bd8a6c8ee049ae
*httpd-2.4.45.tar.gz
sha512:
8b1e9c22371c75efd2466c69ed48782ddcecfe0a3ff143ca3f9cb720ea2aee56f5c323a9e3ae80cd5c44f1601b5894879af03b6b3729a8ca0555bb5193a1296a
*httpd-2.4.45.tar.gz

The SVN tag is '2.4.45' at r1880411.

-- 
Daniel Ruggeri

[RESULT] [VOTE] Release httpd-2.4.44

[Daniel Ruggeri]

On 7/28/2020 12:51 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.44:
> [ ] +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:
> sha1: 5a9eac997db0e466103b09b80ccc0fccc7e46fa3 *httpd-2.4.44.tar.gz
> sha256: a422d30fe9ad9f0c2efcbbb7b56c820d4891cd74d7d55d3853f372193fbf059e
> *httpd-2.4.44.tar.gz
> sha512:
> f9065b30df4d91b70739631e19e65c5a68d4f4ed9071c2b040176b5ee839a86078f178cadd8430f325edda8dddf1ff95c7924e62d73f8f3b6e9b7f48f0b3b257
> *httpd-2.4.44.tar.gz
>
> The SVN tag is '2.4.44' at r1880378.
Hi, all - apologies for the false start. A backport into 2.4 was missed
just before I rolled the release. Since version numbers are cheap and
we've only just begun the testing cycle, I'll close this vote and will
soon roll a 2.4.45 release as replacement.

-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.44

[Daniel Ruggeri]

Hi, Stefan;
   Since version numbers are cheap and we've had only one vote on this
one, I don't see harm in incorporating the change and rerolling. Doubly
so since votes are already in for the change and all that. I'll re-roll
the release tarball once you confirm.

-- 
Daniel Ruggeri

On 7/29/2020 7:02 AM, Stefan Eissing wrote:
> -1.
>
> I have to apologise. I missed an important change in HTTP/2 that I like to 
> get in the release. This is about removing support for an abandoned http-wg 
> draft that we do not want any longer in our server.
>
> Will do the changes right away and let you know when I am done.
>
> Again, sorry to everyone for the wasted cycles. :(
>
> - Stefan
>
>> Am 28.07.2020 um 19:51 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.44:
>> [ ] +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:
>> sha1: 5a9eac997db0e466103b09b80ccc0fccc7e46fa3 *httpd-2.4.44.tar.gz
>> sha256: a422d30fe9ad9f0c2efcbbb7b56c820d4891cd74d7d55d3853f372193fbf059e
>> *httpd-2.4.44.tar.gz
>> sha512:
>> f9065b30df4d91b70739631e19e65c5a68d4f4ed9071c2b040176b5ee839a86078f178cadd8430f325edda8dddf1ff95c7924e62d73f8f3b6e9b7f48f0b3b257
>> *httpd-2.4.44.tar.gz
>>
>> The SVN tag is '2.4.44' at r1880378.
>>
>> -- 
>> Daniel Ruggeri
>>
>>

Re: [VOTE] Release httpd-2.4.44

[Daniel Ruggeri]

+1 from me based on below results

NOTE: httpd does not build against the latest version of LUA (5.4), but
that major bump was just released a few weeks ago.

system:
  kernel:
    name: Linux
    release: 4.19.0-9-amd64
    version: #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07)
    machine: x86_64

  libraries:
    openssl: "1.1.1g"
    openldap: "2.4.50"
    apr: "1.7.0"
    apr-util: "1.6.1"
    iconv: "1.2.2"
    brotli: "1.0.7"
    nghttp2: "1.41.0"
    zlib: "1.2.11"
    pcre: "8.44"
    libxml2: "2.9.9"
    php: "7.4.8"
    lua: "5.3.5"
    curl: "7.71.1"

-- 
Daniel Ruggeri

On 7/28/2020 12:51 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.44:
> [ ] +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:
> sha1: 5a9eac997db0e466103b09b80ccc0fccc7e46fa3 *httpd-2.4.44.tar.gz
> sha256: a422d30fe9ad9f0c2efcbbb7b56c820d4891cd74d7d55d3853f372193fbf059e
> *httpd-2.4.44.tar.gz
> sha512:
> f9065b30df4d91b70739631e19e65c5a68d4f4ed9071c2b040176b5ee839a86078f178cadd8430f325edda8dddf1ff95c7924e62d73f8f3b6e9b7f48f0b3b257
> *httpd-2.4.44.tar.gz
>
> The SVN tag is '2.4.44' at r1880378.
>

[VOTE] Release httpd-2.4.44

[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.44:
[ ] +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:
sha1: 5a9eac997db0e466103b09b80ccc0fccc7e46fa3 *httpd-2.4.44.tar.gz
sha256: a422d30fe9ad9f0c2efcbbb7b56c820d4891cd74d7d55d3853f372193fbf059e
*httpd-2.4.44.tar.gz
sha512:
f9065b30df4d91b70739631e19e65c5a68d4f4ed9071c2b040176b5ee839a86078f178cadd8430f325edda8dddf1ff95c7924e62d73f8f3b6e9b7f48f0b3b257
*httpd-2.4.44.tar.gz

The SVN tag is '2.4.44' at r1880378.

-- 
Daniel Ruggeri

Re: NOTICE: Intent to T late this week

[Daniel Ruggeri]

On 7/28/2020 7:41 AM, Eric Covener wrote:
> On Tue, Jul 28, 2020 at 4:30 AM Christophe JAILLET
>  wrote:
>> Le 27/07/2020 à 14:11, Daniel Ruggeri a écrit :
>>>
>>> On July 27, 2020 2:12:45 AM CDT, Stefan Eissing 
>>>  wrote:
>>>>
>>>>> Am 25.07.2020 um 00:14 schrieb Daniel Ruggeri :
>>>>>
>>>>> Hi, all;
>>>>>FYI, I came across an unexpected set of diffs when rebuilding docs
>>>> before tagging this morning. Haven't forgotten about T, but would
>>>> like to figure out the origin of the docs changes (likely my
>>>> environment). I've started a conversation on docs@ about what I'm
>>>> seeing.
>>>>
>>>> Sorry about your troubles. Do we need to look for someone else doing
>>>> the RMing or what's your status?
>>> Hi, Stefen;
>>> I'm still good to go. I just need clarity on what encoding behavior we 
>>> expect in the docs. More info is on docs@. Either way works for me... just 
>>> need to know what the consensus is.
>>>
>>>>>
>>>>> On 2020/07/22 23:32:05, Daniel Ruggeri  wrote:rance 
>>>>> :))
>>>>>> Hi, all;
>>>>>>It's been a while since we've rolled a release and gotten
>>>> fixes/etc in our community's hands. Apologies for not suggesting this
>>>> sooner. How about a T Friday? That will let vote run through the
>>>> weekend.
>>>>>> --
>>>>>> Daniel Ruggeri
>> Hi,
>>
>> I don't have access to my PC these days (side effect from being on
>> vacation in the south of France :)), however, have a look at r1878788 on
>> trunk which should fixed once and for all the issue.
>>
>> This commit switches the en doc files into utf8 which works great with
>> older and newer versions of Java.
>>
>> To be consistent with the other language, the files themselves should be
>> renamed to have a trailing .utf8, as explained in the commit description.
>>
>> I've not done it on trunk because it is painful (at least for me) to
>> synch all the news .utf8 files with svn. If s.o. feels like making the
>> change, please do.
>>
>> CJ
> Thanks Christophe.  I backported it but did not do the .utf8 extension
> due to the amount of spam it would create.
> I also put some java checks in docs-build
>
> Daniel -- I say proceed w/ release and we can revisit the .utf8 extension 
> later.
>
Excellent! I've performed my prechecks and everything is looking pretty
good. I'll get this moving now.

-- 
Daniel Ruggeri

Re: NOTICE: Intent to T late this week

[Daniel Ruggeri]

On July 27, 2020 2:12:45 AM CDT, Stefan Eissing  
wrote:
>
>
>> Am 25.07.2020 um 00:14 schrieb Daniel Ruggeri :
>> 
>> Hi, all;
>>   FYI, I came across an unexpected set of diffs when rebuilding docs
>before tagging this morning. Haven't forgotten about T, but would
>like to figure out the origin of the docs changes (likely my
>environment). I've started a conversation on docs@ about what I'm
>seeing.
>
>Sorry about your troubles. Do we need to look for someone else doing
>the RMing or what's your status?

Hi, Stefen;
I'm still good to go. I just need clarity on what encoding behavior we expect 
in the docs. More info is on docs@. Either way works for me... just need to 
know what the consensus is.

>
>> 
>> 
>> On 2020/07/22 23:32:05, Daniel Ruggeri  wrote: 
>>> Hi, all;
>>>   It's been a while since we've rolled a release and gotten
>fixes/etc in our community's hands. Apologies for not suggesting this
>sooner. How about a T Friday? That will let vote run through the
>weekend.
>>> -- 
>>> Daniel Ruggeri

Re: NOTICE: Intent to T late this week

[Daniel Ruggeri]

Hi, all;
   FYI, I came across an unexpected set of diffs when rebuilding docs before 
tagging this morning. Haven't forgotten about T, but would like to figure out 
the origin of the docs changes (likely my environment). I've started a 
conversation on docs@ about what I'm seeing.


On 2020/07/22 23:32:05, Daniel Ruggeri  wrote: 
> Hi, all;
>It's been a while since we've rolled a release and gotten fixes/etc in our 
> community's hands. Apologies for not suggesting this sooner. How about a T 
> Friday? That will let vote run through the weekend.
> -- 
> Daniel Ruggeri

Re: NOTICE: Intent to T late this week

[Daniel Ruggeri]

Hey there, Chris;

   Fair question - and I don't think I have a handy link describing the
flow of patch -> trunk -> STATUS backport proposal -> branch commit ->
release

   Generally speaking, the code goes into trunk and is proposed for
backport into a stable branch via the STATUS file (at the root of the
branch - ex
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?view=markup).
A lot of times, patches are proposed for discussion/refined and
tweaked/etc before being committed in trunk, which seems to fit the
conversation in your reference BZ item. From there, we need three
committer +1s to backport. Once all three are in place, the proposer (or
release manager) commits the change to the branch. So, for this one, I
think we're not quite ready to incorporate.

P.S.
I hope all is well - long time no chat!

-- 
Daniel Ruggeri

On 7/23/2020 1:33 PM, Christopher Schultz wrote:
> Daniel,
>
> On 7/22/20 19:32, Daniel Ruggeri wrote:
> > Hi, all; It's been a while since we've rolled a release and gotten
> > fixes/etc in our community's hands. Apologies for not suggesting
> > this sooner. How about a T Friday? That will let vote run through
> > the weekend.
>
> If I clean-up my patch for
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64338 is there a chance
> it could make it into this release?
>
> I'm super-ignorant about the httpd release process so I apologize if
> that's a ridiculous question.
>
> -chris

NOTICE: Intent to T late this week

[Daniel Ruggeri]

Hi, all;
   It's been a while since we've rolled a release and gotten fixes/etc in our 
community's hands. Apologies for not suggesting this sooner. How about a T 
Friday? That will let vote run through the weekend.
-- 
Daniel Ruggeri

Re: RFC: Documenting changes in the CHANGES file

[Daniel Ruggeri]

On 6/1/2020 6:23 AM, Yann Ylavic wrote:
> On Fri, May 29, 2020 at 9:30 PM Ruediger Pluem  wrote:
>> Reviewing our backport process I noticed that in many cases a clean merge 
>> via svn merge fails due to conflicts in CHANGES. While
>> these are easy to solve it puts IMHO unnecessary extra work on the backport 
>> process, both for reviewing and for actually doing the
>> backport. How about if we change the way we document changes the following 
>> way:
>>
>> 1. We create a changes-fragments directory (name to be determined) at the 
>> top level.
>> 2. For each release we create a subdirectory such that we end up with the 
>> following structure:
>>
>>changes-fragments/
>>  2.4.41/
>>  2.4.42/
>>  2.4.43/
>>  2.4.44/
>>
>> 3. Each directory contains the changes for each release and each change 
>> entry is a single file.
>> 4. We have a script that builds our current CHANGES file from the content in 
>> changes-fragments directories with the help of
>>a template or at least some sort of header / footer that is static.
>> 5. This script can be called either manually and we commit the resulting 
>> CHANGES file as we like just like the x-forms commits
>>for documentation plus this script is called by the release scripts from 
>> Daniel as part of the preparation of rolling a
>>release.
> +1 from me, I don't volonteer for the scripts though :)
>
> Regards;
> Yann.

Hi, Yann;

I'm open to whatever... and don't mind writing or tweaking scripts once
we decide on an approach :-)

While we are discussing ideas in this neighborhood, one thing to keep in
mind is that during release of security fixes, sometimes there are items
added to CHANGES and sometimes CHANGES is modified to add CVE
information. There have been minor bumps in the road where these patches
don't always apply cleanly. So, if possible, it would be great to
consider. There may be nothing to do, though, since that happens way
after backport.

-- 
Daniel Ruggeri

Odd vulnerabilities_24.html output

[Daniel Ruggeri]

Hi, all;
   I'm not sure what mechanism is used to generate
https://httpd.apache.org/security/vulnerabilities_24.html from
https://svn.apache.org/repos/asf/httpd/site/trunk/content/security/vulnerabilities-httpd.xml,
but an anomaly has been reported to me in response to the security
announcements from last release.

   For both CVE-2020-1934 and CVE-2020-1927, the source file says
"Apache HTTP Server versions 2.4.0 to 2.4.41" in the description, but
the rendered result is "Apache HTTP Server versions 2.4.0 to 2.41". If
anyone has pointers on how the site build happens, I can look into it
further.

   If it's too complicated a fix, I'm OK with removing that line from
the description. The CVE reports must include the version vulnerability
info in the description, but it's not really a requirement for the site
(I was just keeping them consistent).

-- 
Daniel Ruggeri

[RESULT - PASS][VOTE] Release httpd-2.4.43

[Daniel Ruggeri]

On 3/26/2020 9:50 AM, 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.43:
> [ ] +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:
> sha1: 15d8605b094dfe5e283cd9e90770368dd14e26f2 *httpd-2.4.43.tar.gz
> sha256: 2624e92d89b20483caeffe514a7c7ba93ab13b650295ae330f01c35d5b50d87f
> *httpd-2.4.43.tar.gz
> sha512:
> d9879b8f8ef7d94dee1024e9c25b56d963a3b072520878a88a044629ad577c109a5456791b39016bf4f6672c04bf4a0e5cfd32381211e9acdc81d4a50b359e5e
> *httpd-2.4.43.tar.gz
>
> The SVN tag is '2.4.43' at r1875715.
>

Hi, all;
   I am pleased to report that the vote to release httpd-2.4.43 has
PASSED with the following +1 votes recorded:
PMC
jorton, ylavic, icing, jfclere, jim, steffenal, jailletc36, covener,
gsmith, druggeri, rjung

Community
gbechis

... and zero -1 votes.

I will begin the process of promoting to the mirror system and will prep
for announcement in the next day or two.

-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.43

[Daniel Ruggeri]

On 3/27/2020 12:58 PM, William A Rowe Jr wrote:
> On Fri, Mar 27, 2020 at 12:34 PM Steffen  <mailto:i...@apachelounge.com>> wrote:
>
> +1 All fine on Windows.
>
>
> Your's are still the .dsp based builds, right? I can confirm also on
> the CMake flavor.

Thanks, Bill. Shall this response be considered a +1 for the purposes of
the release vote?

-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.43

[Daniel Ruggeri]

On 3/26/2020 9:50 AM, 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.43:
> [ ] +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:
> sha1: 15d8605b094dfe5e283cd9e90770368dd14e26f2 *httpd-2.4.43.tar.gz
> sha256: 2624e92d89b20483caeffe514a7c7ba93ab13b650295ae330f01c35d5b50d87f
> *httpd-2.4.43.tar.gz
> sha512:
> d9879b8f8ef7d94dee1024e9c25b56d963a3b072520878a88a044629ad577c109a5456791b39016bf4f6672c04bf4a0e5cfd32381211e9acdc81d4a50b359e5e
> *httpd-2.4.43.tar.gz
>
> The SVN tag is '2.4.43' at r1875715.


For my own vote:

[X] +1: It's not just good, it's good enough!

system:
  kernel:
    name: Linux
    release: 4.9.0-8-amd64
    version: #1 SMP Debian 4.9.144-3.1 (2019-02-19)
    machine: x86_64

  libraries:
    openssl: "1.1.1e"
    openldap: "2.4.49"
    apr: "1.7.0"
    apr-util: "1.6.1"
    iconv: "1.2.2"
    brotli: "1.0.7"
    nghttp2: "1.40.0"
    zlib: "1.2.11"
    pcre: "8.44"
    libxml2: "2.9.9"
    php: "7.4.4"
    lua: "5.3.5"
    curl: "7.69.1"

-- 
Daniel Ruggeri

[VOTE] Release httpd-2.4.43

[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.43:
[ ] +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:
sha1: 15d8605b094dfe5e283cd9e90770368dd14e26f2 *httpd-2.4.43.tar.gz
sha256: 2624e92d89b20483caeffe514a7c7ba93ab13b650295ae330f01c35d5b50d87f
*httpd-2.4.43.tar.gz
sha512:
d9879b8f8ef7d94dee1024e9c25b56d963a3b072520878a88a044629ad577c109a5456791b39016bf4f6672c04bf4a0e5cfd32381211e9acdc81d4a50b359e5e
*httpd-2.4.43.tar.gz

The SVN tag is '2.4.43' at r1875715.

-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.42

[Daniel Ruggeri]

Hi, all;
   Per the issues surfaced/fixed, I'll go ahead and declare this release
as dead-on-the vine. I'll target another T later this week, hopefully
after the discussion around OpenSSL versioning plays out.

   How about Thursday?

-- 
Daniel Ruggeri

On 3/19/2020 9:45 AM, 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.42:
> [ ] +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:
> sha1: 2e4505796dfaebcceab6ba22e5fa221e07ad488e *httpd-2.4.42.tar.gz
> sha256:
> cbac6f8211744a74f798db792b74da9f6fb5a4fbee94234cf2b01aeb9ffe57ed
> *httpd-2.4.42.tar.gz
> sha512:
> 09d0f3bd9266907eea91ac9129a3c41658929b9fd88d627c1fccceaf952548d2c3ad62099b9bcd1ae4822402c1dbda90b8bfb9f64cd5eac9f84ed249faffb837
> *httpd-2.4.42.tar.gz
>
> The SVN tag is '2.4.42' at r1875427.
>

[VOTE] Release httpd-2.4.42

[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.42:

[ ] +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:
sha1: 2e4505796dfaebcceab6ba22e5fa221e07ad488e *httpd-2.4.42.tar.gz
sha256: cbac6f8211744a74f798db792b74da9f6fb5a4fbee94234cf2b01aeb9ffe57ed 
*httpd-2.4.42.tar.gz
sha512: 
09d0f3bd9266907eea91ac9129a3c41658929b9fd88d627c1fccceaf952548d2c3ad62099b9bcd1ae4822402c1dbda90b8bfb9f64cd5eac9f84ed249faffb837 *httpd-2.4.42.tar.gz


The SVN tag is '2.4.42' at r1875427.

--
Daniel Ruggeri

[NOTICE] Intenet to T 2.4.42 in the next 36 hours.

[Daniel Ruggeri]

Hi, all;
   It looks like we're in a good place to do a release so I will aim to 
T 2.4.42 tomorrow. Please feel free to shout loudly if any issues are 
found.


--
Daniel Ruggeri

Re: 2.4.42 soon?

[Daniel Ruggeri]

Sure - happy to oblige!
--
Daniel Ruggeri

On 2020-03-13 07:51, Eric Covener wrote:

Looks like STATUS is in good shape.

Any cycles Daniel or Jim?
--
Eric Covener
cove...@gmail.com

Re: svn commit: r1866035 - /httpd/httpd/branches/2.4.x/STATUS

[Daniel Ruggeri]

On February 7, 2020 4:59:39 AM CST, Joe Orton  wrote:
>On Thu, Feb 06, 2020 at 07:52:18AM -0600, Daniel Ruggeri wrote:
>> Hey there, Joe; No idea how I didn't detect this much sooner. I have 
>>access to hardware security modules with PKCS11 interfaces for key
>
>>operations and would be happy to put this through it's paces. The 
>>2.5 docs are fairly light (note, this 2.4 patch seems to be
>missing 
>>docs) on how to test this out. Pointers appreciated if you have a 
>>working recipe.
>
>That would be awesome.  The stuff I'm not really sure about & could use
>
>better docs is:
>
>a) how to identify the right PKCS#11 URI for the key/cert objects, and
>b) how to set up the OpenSSL pkcs11 engine correctly so this works
>
>On recent Fedora/RHEL (b) works OOTB but I imagine this may take some 
>effort on other systems or from-scratch builds.
>
>For testing locally I used a USB smartcard reader, setting up the card 
>following https://github.com/OpenSC/OpenSC/wiki/Quick-Start-with-OpenSC
>
>If you can store a cert & private key on the token, mod_ssl will use 
>both, but I think not all HSMs can store the cert, so you can load that
>
>from a PEM file if required and list the key only as a pkcs11: URI in 
>SSLCertificateKeyFile.
>
>Beyond that it should "just work" if you configure per the mod_ssl
>docs, 
>running "p11tool --list-tokens" listed the URI for the token, and I 
>used:
>
>SSLCertificateFile
>"pkcs11:model=PKCS%2315;manufacturer=OpenSC%20Project;serial=0001C9540200;token=Joe%20Orton%20%28OpenSC%20Card%29"
>
>Regards, Joe

Sweet - this is a good starting point. I'll also get in touch with the 
manufacturer to see if there are any gotchas to worry about. For all I know, it 
may be a non-starter with this particular gear. Hopefully more to come soon!

-- 
Daniel Ruggeri
>
>> 
>> On 2019/08/28 12:15:02 jor...@apache.org wrote:
>> > Author: jorton
>> > Date: Wed Aug 28 12:15:01 2019
>> > New Revision: 1866035
>> > 
>> > URL: http://svn.apache.org/viewvc?rev=1866035=rev
>> > Log:
>> > Proposed mod_ssl PKCS#11 cert/key support.
>> > 
>> > Modified:
>> > httpd/httpd/branches/2.4.x/STATUS
>> > 
>> > Modified: httpd/httpd/branches/2.4.x/STATUS
>> > URL:
>http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1866035=1866034=1866035=diff
>> >
>==
>> > --- httpd/httpd/branches/2.4.x/STATUS (original)
>> > +++ httpd/httpd/branches/2.4.x/STATUS Wed Aug 28 12:15:01 2019
>> > @@ -160,6 +160,21 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>> >rpluem says: -1 for now. See further discussion at
>> >
>https://bz.apache.org/bugzilla/show_bug.cgi?id=63503
>> >  
>> > +   *) mod_ssl: Add support for loading certs & keys from PKCS#11
>URLs via the
>> > +   OpenSSL pkcs11 engine.  Includes related minor
>cleanups and
>> > +   simplification to mod_ssl internals.
>> > +  trunk patch: http://svn.apache.org/r1830819
>> > +   http://svn.apache.org/r1830912
>> > +   http://svn.apache.org/r1830913
>> > +   http://svn.apache.org/r1830927
>> > +   http://svn.apache.org/r1831168
>> > +   http://svn.apache.org/r1831173
>> > +   http://svn.apache.org/r1835240
>> > +   http://svn.apache.org/r1835242
>> > +   http://svn.apache.org/r1835615
>> > +  2.4.x patch:
>http://people.apache.org/~jorton/mod_ssl_pkcs11.patch
>> > +  +1: jorton, 
>> > +
>> >  PATCHES/ISSUES THAT ARE BEING WORKED
>> >[ New entries should be added at the START of the list ]
>> >  
>> > 
>> > 
>> > 
>> -- 
>> Daniel Ruggeri

2.4.next coming?

[Daniel Ruggeri]

Hi, all. It's been a few months since we've rolled a release and there are a 
few bug fixes that seem like A Good Thing to get out there.

Thoughts on rolling soon-ish?

As always, I volunteer to either RM or mentor someone new through the RM 
process.
-- 
Daniel Ruggeri

RE: svn commit: r1866035 - /httpd/httpd/branches/2.4.x/STATUS

[Daniel Ruggeri]

Hey there, Joe;
   No idea how I didn't detect this much sooner. I have access to hardware 
security modules with PKCS11 interfaces for key operations and would be happy 
to put this through it's paces. The 2.5 docs are fairly light (note, this 2.4 
patch seems to be missing docs) on how to test this out. Pointers appreciated 
if you have a working recipe.

On 2019/08/28 12:15:02 jor...@apache.org wrote:
> Author: jorton
> Date: Wed Aug 28 12:15:01 2019
> New Revision: 1866035
> 
> URL: http://svn.apache.org/viewvc?rev=1866035=rev
> Log:
> Proposed mod_ssl PKCS#11 cert/key support.
> 
> Modified:
> httpd/httpd/branches/2.4.x/STATUS
> 
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1866035=1866034=1866035=diff
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Wed Aug 28 12:15:01 2019
> @@ -160,6 +160,21 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>rpluem says: -1 for now. See further discussion at
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63503
>  
> +   *) mod_ssl: Add support for loading certs & keys from PKCS#11 URLs via the
> +   OpenSSL pkcs11 engine.  Includes related minor cleanups and
> +   simplification to mod_ssl internals.
> +  trunk patch: http://svn.apache.org/r1830819
> +   http://svn.apache.org/r1830912
> +   http://svn.apache.org/r1830913
> +   http://svn.apache.org/r1830927
> +   http://svn.apache.org/r1831168
> +   http://svn.apache.org/r1831173
> +   http://svn.apache.org/r1835240
> +   http://svn.apache.org/r1835242
> +   http://svn.apache.org/r1835615
> +  2.4.x patch: http://people.apache.org/~jorton/mod_ssl_pkcs11.patch
> +  +1: jorton, 
> +
>  PATCHES/ISSUES THAT ARE BEING WORKED
>[ New entries should be added at the START of the list ]
>  
> 
> 
> 
-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.41

[Daniel Ruggeri]

On 8/9/2019 8:50 AM, sebb wrote:
> On Fri, 9 Aug 2019 at 14:40, 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.41:
>> [ ] +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:
>> sha1: b713e835aa7cde823a4b7f8e3463164f3d9fe63e *httpd-2.4.41.tar.gz
>> sha256: 3c0f9663240beb0f008acf3b4501c4f339d7467ee345a36c86c46b4d6f3a5461 
>> *httpd-2.4.41.tar.gz
> I think it would be helpful to include the SVN repo tag and revision.
> This is needed to show provenance for the archive contents.
Sure - easy to handle. I've updated the email template in r1872960 for
the site repo

-- 
Daniel Ruggeri

>
>> --
>> Daniel Ruggeri

Re: svn commit: r1865191 - /httpd/site/trunk/tools/announce.sh

[Daniel Ruggeri]

On 8/30/2019 4:57 AM, Ruediger Pluem wrote:
>
> On 08/14/2019 11:01 PM, drugg...@apache.org wrote:
>> Author: druggeri
>> Date: Wed Aug 14 21:01:56 2019
>> New Revision: 1865191
>>
>> URL: http://svn.apache.org/viewvc?rev=1865191=rev
>> Log:
>> Try to be more accomodating
>>
>> Modified:
>> httpd/site/trunk/tools/announce.sh
>>
>> Modified: httpd/site/trunk/tools/announce.sh
>> URL: 
>> http://svn.apache.org/viewvc/httpd/site/trunk/tools/announce.sh?rev=1865191=1865190=1865191=diff
>> ==
>> --- httpd/site/trunk/tools/announce.sh (original)
>> +++ httpd/site/trunk/tools/announce.sh Wed Aug 14 21:01:56 2019
>> @@ -93,30 +93,29 @@ echo "Checking $dir..."
>>#Flip the bit
>>is_security_release=1
>>  
>> -  #If this is in the section not-yet-ready for announce, apply the
>> -  # patch before moving on to announcement generation
>> -  if echo "$SHORT_STATUS" | sed -n '/CHANGES READY FOR REPLACEMENT/,/##/p' 
>> | grep "$dir" >/dev/null;then
>> -#Apply our CHANGES updates via CHANGES.diff or CHANGES
>> -#TODO: Verify that one and only one of the two options will be present 
>> at all times
>> -if test -f "$private_base"/SECURITY/$dir/CHANGES.diff;then
>> -  patch -p0 -d "$branch_base" < 
>> "$private_base"/SECURITY/$dir/CHANGES.diff 
>> -  patch -p0 -d "$release_base" < 
>> "$private_base"/SECURITY/$dir/CHANGES.diff 
>> -elif test -f "$private_base"/SECURITY/$dir/CHANGES;then
>> -  for UPDATE_FILE in "$branch_base"/CHANGES "$release_base"/CHANGES;do
>> -VERSION="$version" UPDATE_FILE="$UPDATE_FILE" STATUS_UPDATE=`cat 
>> "$private_base"/SECURITY/$dir/CHANGES` perl -e '
>> -  $ENV{STATUS_UPDATE} =~ s/^\s*$//g;
>> -  die "Status update not found!" if !$ENV{STATUS_UPDATE};
>> -  open(CHANGES, "$ENV{UPDATE_FILE}"); my @content=; 
>> close(CHANGES);
>> -  foreach my $line (@content) {
>> -print "$line";
>> -if (!$added && $line =~ /Changes with Apache $ENV{VERSION}/i) {
>> -  print "\n$ENV{STATUS_UPDATE}\n";
>> -}
>> +  #Opportunisticly apply patches to CHANGES regardless of section (announce 
>> ready vs changes ready)
>> +  #because sometimes things are placed in announce ready even though they 
>> haven't had the CHANGES fix applied
>> +  if test -f "$private_base"/SECURITY/$dir/CHANGES.diff;then
>> +patch -p0 -d "$branch_base" < 
>> "$private_base"/SECURITY/$dir/CHANGES.diff 
>> +patch -p0 -d "$release_base" < 
>> "$private_base"/SECURITY/$dir/CHANGES.diff 
>> +  elif test -f "$private_base"/SECURITY/$dir/CHANGES;then
>> +for UPDATE_FILE in "$branch_base"/CHANGES "$release_base"/CHANGES;do
>> +  VERSION="$version" UPDATE_FILE="$UPDATE_FILE" STATUS_UPDATE=`cat 
>> "$private_base"/SECURITY/$dir/CHANGES` perl -e '
>> +$ENV{STATUS_UPDATE} =~ s/^\s*$//g;
>> +die "Status update not found!" if !$ENV{STATUS_UPDATE};
>> +open(CHANGES, "$ENV{UPDATE_FILE}"); my @content=; 
>> close(CHANGES);
>> +foreach my $line (@content) {
>> +  print "$line";
>> +  if (!$added && $line =~ /Changes with Apache $ENV{VERSION}/i) {
> What is the purpose of the $added variable?

Yikes! This fell between the cracks. Sorry for the really slow reply.

The $added variable was intended to use as a failsafe signal. If we
attempt to add the CHANGES entry, but didn't do so for some reason, the
perl script should fail. I somehow crossed my wires and missed the
important part of bailing out when that happens.

This has been fixed in r1872959

-- 
Daniel Ruggeri

>
>> +print "\n$ENV{STATUS_UPDATE}\n";
>>}
>> -' > "$scratch"/tmp_status
>> -mv "$scratch"/tmp_status "$UPDATE_FILE"
>> -  done
>> -else
>> +}
>> +  ' > "$scratch"/tmp_status
>> +  mv "$scratch"/tmp_status "$UPDATE_FILE"
>> +done
>> +  else
>> +#Fail if this is in the changes ready section, but we didn't find a 
>> change
>> +if echo "$SHORT_STATUS" | sed -n '/CHANGES READY FOR 
>> REPLACEMENT/,/##/p' | grep "$dir" >/dev/null;then
>>echo "Missing CHANGES.diff or CHANGES file for $dir"
>>exit 1
>>  fi
>>
> Regards
>
> Rüdiger
>

Re: CVE-2019-10097 vs. CHANGEs entry

[Daniel Ruggeri]

Ah, yes... Not sure how I made that error. Just fixed!
-- 
Daniel Ruggeri

On August 17, 2019 9:41:42 AM CDT, Stefan Fritsch  wrote:
>Hi,
>
>Shouldn't CVE-2019-10097 be listed under 2.4.41, too?
>
>Cheers,
>Stefan
>
>--- httpd/httpd/branches/2.4.x/CHANGES 2019/08/14 20:43:00 1865188
>+++ httpd/httpd/branches/2.4.x/CHANGES 2019/08/14 20:52:45 1865189
>@@ -1,8 +1,39 @@
>  -*- coding:
>utf-8 -*-
> Changes with Apache 2.4.42
>
>+  *) SECURITY: CVE-2019-10097 (cve.mitre.org)
>+ mod_remoteip: Fix stack buffer overflow and NULL pointer
>deference
>+ when reading the PROXY protocol header.  [Joe Orton,
>+ Daniel McCarney ]
>+
> Changes with Apache 2.4.41
>
>+  *) SECURITY: CVE-2019-9517 (cve.mitre.org)
>+ mod_http2: a malicious client could perform a DoS attack by
>flooding
>+a connection with requests and basically never reading
>responses
>+on the TCP connection. Depending on h2 worker dimensioning, it
>was
>+possible to block those with relatively few connections.
>[Stefan Eissing]
>+

[RESULT][VOTE] Release httpd-2.4.41

[Daniel Ruggeri]

Hi, all;
   It is my pleasure to confirm that we have received enough votes to
PASS the release of httpd-2.4.41! As always, I thank everyone for their
diligence in testing this release and am very happy we caught the minor
regression during 2.4.40 validation cycles to prevent a potentially
impacting situation for users. Awesome, y'all!

I detected the following +1 votes:
PMC
jailletc36, druggeri, humbedooh, icing, steffenal, jim, covener, jorton,
rjung

Community
Dennis Clarke, Noel Butler

No -1 votes were recorded.

I will begin the process of promoting the release to the dist locations
and will prep for announcement in 48-ish hours.

-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.41

[Daniel Ruggeri]

On 2019/08/09 13:40:38, 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.41:
> [ ] +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:
> sha1: b713e835aa7cde823a4b7f8e3463164f3d9fe63e *httpd-2.4.41.tar.gz
> sha256: 3c0f9663240beb0f008acf3b4501c4f339d7467ee345a36c86c46b4d6f3a5461  
> *httpd-2.4.41.tar.gz
> -- 
> Daniel Ruggeri

+1 from me.

Tested under the following conditions...

system:
  kernel:
name: Linux
release: 4.9.0-8-amd64
version: #1 SMP Debian 4.9.144-3 (2019-02-02)
machine: x86_64

  libraries:
openssl: "1.1.1c"
openldap: "2.4.48"
apr: "1.7.0"
apr-util: "1.6.1"
iconv: "1.2.2"
brotli: "1.0.7"
nghttp2: "1.39.1"
    zlib: "1.2.11"
pcre: "8.43"
libxml2: "2.9.9"
php: "7.3.8"
lua: "5.3.5"
curl: "7.65.3"

-- 
Daniel Ruggeri

[VOTE] Release httpd-2.4.41

[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.41:
[ ] +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:
sha1: b713e835aa7cde823a4b7f8e3463164f3d9fe63e *httpd-2.4.41.tar.gz
sha256: 3c0f9663240beb0f008acf3b4501c4f339d7467ee345a36c86c46b4d6f3a5461  
*httpd-2.4.41.tar.gz
-- 
Daniel Ruggeri

Re: [NOTICE] Intent to T 2.4.41 in ~24 hrs

[Daniel Ruggeri]

Yessir. I'll send a notification when ready.
-- 
Daniel Ruggeri

On August 8, 2019 11:54:18 AM CDT, Dennis Clarke  wrote:
>On 8/8/19 7:41 AM, Daniel Ruggeri wrote:
>> Hi, all;
>> As the subject says, I'd like to get on with our 2.4.new release now
>> that we're good to go. Will kick things off in about 24 hours
>
>Tarballs will be in the usual places ??
>
>
>
>-- 
>Dennis Clarke
>RISC-V/SPARC/PPC/ARM/CISC
>UNIX and Linux spoken
>GreyBeard and suspenders optional

Re: svn commit: r1864701 - /httpd/httpd/branches/2.4.x/STATUS

[Daniel Ruggeri]

+1
-- 
Daniel Ruggeri

On August 8, 2019 8:09:57 AM CDT, Eric Covener  wrote:
>CC dev@ I assumed this was safe to just assert.
>
>On Thu, Aug 8, 2019 at 9:08 AM  wrote:
>>
>> Author: covener
>> Date: Thu Aug  8 13:08:33 2019
>> New Revision: 1864701
>>
>> URL: http://svn.apache.org/viewvc?rev=1864701=rev
>> Log:
>> no votes for APLOGNO commits.
>>
>> 99% sure but please reply
>>
>>
>> Modified:
>> httpd/httpd/branches/2.4.x/STATUS
>>
>> Modified: httpd/httpd/branches/2.4.x/STATUS
>> URL:
>http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1864701=1864700=1864701=diff
>>
>==
>> --- httpd/httpd/branches/2.4.x/STATUS (original)
>> +++ httpd/httpd/branches/2.4.x/STATUS Thu Aug  8 13:08:33 2019
>> @@ -122,6 +122,7 @@ CURRENT RELEASE NOTES:
>>  . documentation
>>  . non-Unix build
>>  . non-Unix, single-platform code
>> +. routine APLOGNO() backports
>>
>>  RELEASE SHOWSTOPPERS:
>>
>>
>>
>
>
>-- 
>Eric Covener
>cove...@gmail.com

[NOTICE] Intent to T 2.4.41 in ~24 hrs

[Daniel Ruggeri]

Hi, all;
   As the subject says, I'd like to get on with our 2.4.new release now that 
we're good to go. Will kick things off in about 24 hours
-- 
Daniel Ruggeri

[RESULT] [VOTE] Release httpd-2.4.40

[Daniel Ruggeri]

Hi, All;
   As discussed on this list, a minor regression has been detected with a fix 
in flight. I'll go ahead and terminate this release vote and will plan to T 
again in the near future with the fix in place.

Thanks to all who prepped for testing. Keep those testing rigs warm - we'll be 
back again soon!
-- 
Daniel Ruggeri

On August 3, 2019 8:51:07 AM CDT, 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.40:
>[ ] +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:
>sha1: 31bc6f87ac209010b8b364abc1c80dfaee53cc64 *httpd-2.4.40.tar.gz
>sha256:
>451e6cf6caa09119900b74652266427f70050de5c51948acd4aaaf60d0d3cad0
>*httpd-2.4.40.tar.gz
>
>-- 
>Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.40

[Daniel Ruggeri]

Thanks, Jan;
   I'm afraid I have no way to verify or dig into Windows-specific issues. Can 
you share more information or errors that can help, or is this related to the 
things already discussed on the list?
-- 
Daniel Ruggeri

On August 4, 2019 6:33:58 AM CDT, Jan Ehrhardt  wrote:
>Gregg Smith in gmane.comp.apache.devel (Sat, 3 Aug 2019 08:43:21
>-0700):
>>Opps, looks like the APLOGNO's didn't get filled in. I'm still ok with
>
>>releasing .40 w/o them.
>>
>>mod_md.c(386): warning C4003: not enough actual parameters for macro 
>>'APLOGNO'
>>mod_md.c(391): warning C4003: not enough actual parameters for macro 
>>'APLOGNO'
>>mod_md.c(601): warning C4003: not enough actual parameters for macro 
>>'APLOGNO'
>>mod_md.c(608): warning C4003: not enough actual parameters for macro 
>>'APLOGNO'
>>mod_md.c(659): warning C4003: not enough actual parameters for macro 
>>'APLOGNO'
>>mod_md.c(702): warning C4003: not enough actual parameters for macro 
>>'APLOGNO'
>>mod_md.c(912): warning C4003: not enough actual parameters for macro 
>>'APLOGNO'
>
>My conclusion after testing a lot of Visual Studio builds: mod_md.so is
>broken. At least on Windows, but probably on any other OS as well. Do
>not release this version.
>-- 
>Jan

Re: svn commit: r1856807 - /httpd/test/framework/trunk/t/security/CVE-2019-0215.t

[Daniel Ruggeri]

On 8/4/2019 3:30 AM, Rainer Jung wrote:
> Hi there,
>
> this one fails for me when the server uses OpenSSL 1.1.1 (no other
> variant tested yet) but the client uses something before 1.1.1. In
> this case I get Status 500 instead of the expected 403 in the client.
>
> Another older test t/security/CVE-2005-2700.t uses
>
> ok !t_cmp($r->code, 200, "...
>
> instead of
>
> ok t_cmp($r->code, 403, "...
>
> used in the new test. Do others observe the same problem? Should we
> relax the condition on 403 or 500, or is it necessary to only relax if
> client isn't using 1.1.1 (or maybe depending on effective TLS version)?

I also see the same problem. The 500 must be coming from the LWP client
rather than httpd, though, as httpd does log the 403. I would prefer to
skip the test for non-compatible clients rather than for the internal
client error to be treated as a "pass" of a test it cannot run.

-- 
Daniel Ruggeri

>
> Regards,
>
> Rainer
>
> Am 02.04.2019 um 12:44 schrieb jor...@apache.org:
>> Author: jorton
>> Date: Tue Apr  2 10:44:12 2019
>> New Revision: 1856807
>>
>> URL: http://svn.apache.org/viewvc?rev=1856807=rev
>> Log:
>> Add test case for CVE-2019-0215.
>>
>> Added:
>>  httpd/test/framework/trunk/t/security/CVE-2019-0215.t
>>
>> Added: httpd/test/framework/trunk/t/security/CVE-2019-0215.t
>> URL:
>> http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/security/CVE-2019-0215.t?rev=1856807=auto
>> ==
>>
>> --- httpd/test/framework/trunk/t/security/CVE-2019-0215.t (added)
>> +++ httpd/test/framework/trunk/t/security/CVE-2019-0215.t Tue Apr  2
>> 10:44:12 2019
>> @@ -0,0 +1,26 @@
>> +use strict;
>> +use warnings FATAL => 'all';
>> +
>> +use Apache::Test;
>> +use Apache::TestUtil;
>> +use Apache::TestRequest;
>> +
>> +my $vars = Apache::Test::vars();
>> +
>> +plan tests => 2, need $vars->{ssl_module_name}, need_lwp,
>> +    qw(LWP::Protocol::https);
>> +
>> +Apache::TestRequest::user_agent_keepalive(1);
>> +Apache::TestRequest::scheme('https');
>> +Apache::TestRequest::module('ssl_optional_cc');
>> +
>> +my $r;
>> +
>> +$r = GET "/require/any/";
>> +
>> +ok t_cmp($r->code, 403, "first access denied without ccert");
>> +
>> +$r = GET "/require/any/";
>> +
>> +ok t_cmp($r->code, 403, "second access denied without ccert");
>> +

[VOTE] Release httpd-2.4.40

[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.40:
[ ] +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:
sha1: 31bc6f87ac209010b8b364abc1c80dfaee53cc64 *httpd-2.4.40.tar.gz
sha256: 451e6cf6caa09119900b74652266427f70050de5c51948acd4aaaf60d0d3cad0
*httpd-2.4.40.tar.gz

-- 
Daniel Ruggeri

Re: Vote thread for 2.4.40 not started yet?

[Daniel Ruggeri]

Ahhh! I did send a VOTE email, but it looks like it never made it
through to the list!

I will retry from my ASF address through the ASF mail relay...

Date: Fri, 02 Aug 2019 15:18:57 -0500
From: Daniel Ruggeri 
To: dev@httpd.apache.org
Subject: [VOTE] Release httpd-2.4.40
Message-ID: 
X-Sender: drugg...@primary.net
User-Agent: Roundcube Webmail/0.9.2

-- 
Daniel Ruggeri

On 8/3/2019 6:43 AM, Rainer Jung wrote:
> Hi Daniel,
>
> did you forget to start the vote thread or are the uploads not ready yet?
>
> Thanks and regards,
>
> Rainer
>
> Am 02.08.2019 um 22:18 schrieb drugg...@apache.org:
>> Author: druggeri
>> Date: Fri Aug  2 20:18:19 2019
>> New Revision: 35120
>>
>> Log:
>> Add 2.4.40 files
>>
>> Added:
>>  dev/httpd/CHANGES_2.4
>>  dev/httpd/CHANGES_2.4.40
>>  dev/httpd/httpd-2.4.40-deps.tar.bz2   (with props)
>>  dev/httpd/httpd-2.4.40-deps.tar.bz2.asc
>>  dev/httpd/httpd-2.4.40-deps.tar.bz2.md5
>>  dev/httpd/httpd-2.4.40-deps.tar.bz2.sha1
>>  dev/httpd/httpd-2.4.40-deps.tar.bz2.sha256
>>  dev/httpd/httpd-2.4.40-deps.tar.gz   (with props)
>>  dev/httpd/httpd-2.4.40-deps.tar.gz.asc
>>  dev/httpd/httpd-2.4.40-deps.tar.gz.md5
>>  dev/httpd/httpd-2.4.40-deps.tar.gz.sha1
>>  dev/httpd/httpd-2.4.40-deps.tar.gz.sha256
>>  dev/httpd/httpd-2.4.40.tar.bz2   (with props)
>>  dev/httpd/httpd-2.4.40.tar.bz2.asc
>>  dev/httpd/httpd-2.4.40.tar.bz2.md5
>>  dev/httpd/httpd-2.4.40.tar.bz2.sha1
>>  dev/httpd/httpd-2.4.40.tar.bz2.sha256
>>  dev/httpd/httpd-2.4.40.tar.gz   (with props)
>>  dev/httpd/httpd-2.4.40.tar.gz.asc
>>  dev/httpd/httpd-2.4.40.tar.gz.md5
>>  dev/httpd/httpd-2.4.40.tar.gz.sha1
>>  dev/httpd/httpd-2.4.40.tar.gz.sha256
>> Modified:
>>  dev/httpd/Announcement2.4.html
>>  dev/httpd/Announcement2.4.txt
>>
>> Modified: dev/httpd/Announcement2.4.html
>> ==
>>
>> --- dev/httpd/Announcement2.4.html (original)
>> +++ dev/httpd/Announcement2.4.html Fri Aug  2 20:18:19 2019
>> @@ -49,7 +49,7 @@
>>   
>>     
>> -   Apache HTTP Server 2.4.39 Released
>> +   Apache HTTP Server 2.4.40 Released
>>   
>>   
>>  September 21, 2018
>> @@ -57,7 +57,7 @@
>>   
>>  The Apache Software Foundation and the Apache HTTP Server
>> Project are
>>  pleased to > href="https://www.apache.org/dist/httpd/Announcement2.4.html;>announce
>> -   the release of version 2.4.39 of the Apache
>> +   the release of version 2.4.40 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.39 is available for download from:
>> +   Apache HTTP Server 2.4.40 is available for download from:
>>   
>>   
>>     https://httpd.apache.org/download.cgi;
>> @@ -77,7 +77,7 @@
>>   
>>   
>>  Please see the CHANGES_2.4 file,
>> linked from the download page, for a
>> -   full list of changes.  A condensed list, > href="./CHANGES_2.4.39">CHANGES_2.4.39 includes only
>> +   full list of changes.  A condensed list, > href="./CHANGES_2.4.40">CHANGES_2.4.40 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: dev/httpd/Announcement2.4.txt
>> ==
>>
>> --- dev/httpd/Announcement2.4.txt (original)
>> +++ dev/httpd/Announcement2.4.txt Fri Aug  2 20:18:19 2019
>> @@ -1,9 +1,9 @@
>> -    Apache HTTP Server 2.4.39 Released
>> +    Apache HTTP Server 2.4.40 Released
>>    September 21, 2018
>>    The Apache Software Foundation and the Apache HTTP Server Project
>> -   are pleased to announce the release of version 2.4.39 of the Apache
>> +   are pleased to announce the release of version 2.4.40 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
&g

Re: NOTICE: Intent to T Friday

[Daniel Ruggeri]

Hrm... I see this never made it to the list! Retrying from my apache.org 
address...
-- 
Daniel Ruggeri
Director, VP Fundraising, member, httpd PMC
The Apache Software Foundation

On July 31, 2019 8:18:41 AM CDT, Daniel Ruggeri  wrote:
>Hi, all
>I see we have a number of backports ready to go for 2.4.next. I would
>like to go ahead and tag and roll a release Friday morning. Assuming
>there are no objections, I will aim to do this in the morning Central
>us time.
>
>Feel free to start gearing up your test environments!
>-- 
>Daniel Ruggeri

DRuggeri has a new PGP key

[Daniel Ruggeri]

Hi, all;
   As signers or users of my GPG pubkey, I wanted to inform you that I
have generated a new PGP key (DC55C003). I will no longer use my
previous PGP key (1AD84DFF) after this message and am deleting the
private component. Please find the details of the new key below.

pub   4096R/DC55C003 2019-05-11
  Key fingerprint = E348 0043 5956 21FE 5610  5F11 2AB1 2A7A DC55 C003
uid  Daniel Ruggeri (http://home.apache.org/~druggeri/)

uid  Daniel Ruggeri 
uid  [jpeg image of size 13027]
sub   4096R/14FF4720 2019-05-11


It would be appreciated if you could sign the new key *if you trust the
following measures to establish identity*:
 - This message is signed with the previous PGP private key
 - The new key is signed by the previous key and is published to
pgp.mit.edu
 - I committed the new pubkey to
https://dist.apache.org/repos/dist/release/httpd/KEYS in r33993
 - The new key has been added to my ASF LDAP listing (and will be
visible in the next 24 hours) at
https://home.apache.org/keys/committer/druggeri
 - This message was sent through The ASF's mail relay system

Thanks!
-- 
Daniel Ruggeri
Director, VP Fundraising, member, httpd PMC
The Apache Software Foundation





signature.asc
Description: OpenPGP digital signature

Re: ApacheCon call for presentations, httpd content

[Daniel Ruggeri]

Hi, Rich;
   I was looking at the CFP and didn't quite see something that aligns with 
httpd. These are the categories allowed:
General
Community
Tomcat
Big Data
Machine Learning
IoT
Geospatial
Cassandra
Traffic Control Summit
Cloudstack Collaboration Conference
Integration
Graph Processing
Karaf
Drill
Observability
Beam

*maybe* that has has an effect on folks' submissions? Dunno... I just submitted 
in "general"
-- 
Daniel Ruggeri

On 2019/05/01 20:35:49, Rich Bowen  wrote: 
> Hi, folks.
> 
> The call for presentations for ApacheCon North America closes in a
> little less than two weeks. As of right now, as far as I can tell, there
> is exactly zero httpd content.
> 
> If we want to have our project represented at ApacheCon this year, what
> would you want to see? Is there any chance we can fill a half-day of
> content (ie, 3-4 talks) with what new things have happened in the past
> year, and what's important now?
> 
> Personally, I'd like to see a presentation on using mod_md, and perhaps
> something on the benefits of, and use of, http2 in httpd?
> 
> The CFP is here - https://www.apachecon.com/acna19/cfp.html - and closes
> May 13th.
> 
> Thanks!
> 
> --Rich
> 

Re: ApacheCon call for presentations, httpd content

[Daniel Ruggeri]

I'm always willing to give the cookbook talk for the proxy. Sometimes we have 
great questions and conversation... sometimes not. I'll submit that tomorrow 
and we'll see where it goes.

If there is a specific area I have expertise in, I'm happy to develop a 
presentation... (I just don't think I have enough time to develop expertise in 
mod_md or H2) so keep the suggestions coming.

What about a "stupid httpd tricks" kind of talk which is an amalgamation of 
neat stuff? I'm sure we could come up with at least two dozen examples EASILY.
-- 
Daniel Ruggeri

On May 1, 2019 3:35:49 PM CDT, Rich Bowen  wrote:
>Hi, folks.
>
>The call for presentations for ApacheCon North America closes in a
>little less than two weeks. As of right now, as far as I can tell,
>there
>is exactly zero httpd content.
>
>If we want to have our project represented at ApacheCon this year, what
>would you want to see? Is there any chance we can fill a half-day of
>content (ie, 3-4 talks) with what new things have happened in the past
>year, and what's important now?
>
>Personally, I'd like to see a presentation on using mod_md, and perhaps
>something on the benefits of, and use of, http2 in httpd?
>
>The CFP is here - https://www.apachecon.com/acna19/cfp.html - and
>closes
>May 13th.
>
>Thanks!
>
>--Rich

re: svn commit: r33393 - /release/httpd/CHANGES_2.4

[Daniel Ruggeri]

The announcement message was also rejected by moderators because we don't have 
KEYS directly linked on the download page.

I will correct both (about three hrs from now) and reattempt announcement.
-- 
Daniel Ruggeri

On April 2, 2019 1:01:31 AM CDT, Marion et Christophe JAILLET 
 wrote:
>Hi,
>
> 
>
>CHANGES_2.4 has been updated with the SECURITY tags and is available
>from httpd.a.o.
>
>However, http://www.apache.org/dist/httpd/CHANGES_2.4.39 still reflects
>the file without these SECURITY items.
>
> 
>
>I won't be able to update it before Friday, so feel free to fix it in
>the meantime.
>
> 
>
>CJ
>
> 
>
> 
>
> 
>
>> Message du 02/04/19 03:04
>> De : drugg...@apache.org
>> A : c...@httpd.apache.org
>> Copie à : 
>> Objet : svn commit: r33393 - /release/httpd/CHANGES_2.4
>> 
>> Author: druggeri
>> Date: Tue Apr 2 01:04:50 2019
>> New Revision: 33393
>> 
>> Log:
>> Correct changelog for vulnerabilities
>> 
>> Modified:
>> release/httpd/CHANGES_2.4
>> 
>> Modified: release/httpd/CHANGES_2.4
>>
>==
>> --- release/httpd/CHANGES_2.4 (original)
>> +++ release/httpd/CHANGES_2.4 Tue Apr 2 01:04:50 2019
>> @@ -1,13 +1,50 @@
>> -*- coding: utf-8 -*-
>> Changes with Apache 2.4.39
>> + *) SECURITY: CVE-2019-0197 (cve.mitre.org)
>> + mod_http2: fixes a possible crash when HTTP/2 was enabled for a
>http:
>> + host or H2Upgrade was enabled for h2 on a https: host. An Upgrade
>> + request from http/1.1 to http/2 that was not the first request on a
>> + connection could lead to a misconfiguration and crash. Servers that
>> + never enabled the h2 protocol or only enabled it for https: and
>> + did not set "H2Upgrade on" are unaffected by this issue.
>> + [Stefan Eissing]
>> +
>> + *) SECURITY: CVE-2019-0196 (cve.mitre.org)
>> + mod_http2: using fuzzed network input, the http/2 request
>> + handling could be made to access freed memory in string
>> + comparision when determining the method of a request and
>> + thus process the request incorrectly. [Stefan Eissing]
>> +
>> + *) SECURITY: CVE-2019-0211 (cve.mitre.org)
>> + MPMs unix: Fix a local priviledge escalation vulnerability by not
>> + maintaining each child's listener bucket number in the scoreboard,
>> + preventing unprivileged code like scripts run by/on the server
>(e.g. via
>> + mod_php) from modifying it persistently to abuse the priviledged
>main
>> + process. [Charles Fol , Yann Ylavic]
>> +
>> + *) SECURITY: CVE-2019-0196 (cve.mitre.org)
>> + mod_http2: using fuzzed network input, the http/2 request
>> + handling could be made to access freed memory in string
>> + comparision when determining the method of a request and
>> + thus process the request incorrectly. [Stefan Eissing]
>> +
>> + *) SECURITY: CVE-2019-0217 (cve.mitre.org)
>> + mod_auth_digest: Fix a race condition checking user credentials
>which
>> + could allow a user with valid credentials to impersonate another,
>> + under a threaded MPM. PR 63124. [Simon Kappel ]
>> +
>> + *) SECURITY: CVE-2019-0215 (cve.mitre.org)
>> + mod_ssl: Fix access control bypass for per-location/per-dir client
>> + certificate verification in TLSv1.3.
>> +
>> + *) SECURITY: CVE-2019-0220 (cve.mitre.org)
>> + Merge consecutive slashes in URL's. Opt-out with
>> + `MergeSlashes OFF`. [Eric Covener]
>> 
>> *) mod_proxy/ssl: Cleanup per-request SSL configuration anytime a
>backend
>> connection is recycled/reused to avoid a possible crash with some
>SSLProxy
>> configurations in or context. PR 63256. [Yann Ylavic]
>> 
>> - *) mod_ssl: Correctly restore SSL verify state after TLSv1.3 PHA
>failure.
>> - [Michael Kaufmann ]
>> -
>> *) mod_log_config: Support %{c}h for conn-hostname, %h for
>useragent_host
>> PR 55348
>> 
>> @@ -59,13 +96,6 @@ Changes with Apache 2.4.39
>> *) mod_cache_socache: Avoid reallocations and be safe with outgoing
>data
>> lifetime. [Yann Ylavic]
>> 
>> - *) MPMs unix: bind the bucket number of each child to its slot
>number, for a
>> - more efficient per bucket maintenance. [Yann Ylavic]
>> -
>> - *) mod_auth_digest: Fix a race condition. Authentication with valid
>> - credentials could be refused in case of concurrent accesses from
>> - different users. PR 63124. [Simon Kappel ]
>> -
>> *) mod_http2: enable re-use of slave connections again. Fixed slave
>connection
>> keepalives counter. [Stefan Eissing]
>> 
>> 
>> 
>>

[RESULT][VOTE] Release httpd-2.4.39

[Daniel Ruggeri]

Hi, all;
   I am pleased to report that the vote has PASSED with the following
recorded votes:
+1: jorton, icing, jim, ylavic, covener, rjung, druggeri
+0: cjaillet (apparent test system issue)

Thanks to everyone who took the time to test and vote as well as the
work that went into the release itself!
I shall forthwith begin the distribution of the release tarball to the
mirrors.

-- 
Daniel Ruggeri

On 3/27/2019 10:09 AM, 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.39:
> [ ] +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:
> sha1: e66d6bfea42254e64d3b5009f49ecc486ac46de2 *httpd-2.4.39.tar.gz
> sha256:
> 8b95fe249f3a6c50aad3ca125eef3e02d619116cde242e1bc3c266b7b5c37c30
> *httpd-2.4.39.tar.gz
>

Re: [VOTE] Release httpd-2.4.39

[Daniel Ruggeri]

On 3/27/2019 10:09 AM, 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.39:
> [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:
> sha1: e66d6bfea42254e64d3b5009f49ecc486ac46de2 *httpd-2.4.39.tar.gz
> sha256:
> 8b95fe249f3a6c50aad3ca125eef3e02d619116cde242e1bc3c266b7b5c37c30
> *httpd-2.4.39.tar.gz
>

+1 from me with the following test system:


  kernel:
    name: Linux
    release: 4.9.0-8-amd64
    version: #1 SMP Debian 4.9.144-3 (2019-02-02)
    machine: x86_64

  libraries:
    openssl: "1.1.1a"
    openldap: "2.4.47"
    apr: "1.6.5"
    apr-util: "1.6.1"
    iconv: "1.2.2"
    brotli: "1.0.7"
    nghttp2: "1.35.1"
    zlib: "1.2.11"
    pcre: "8.42"
    libxml2: "2.9.9"
    php: "7.3.3"
    lua: "5.3.5"
    curl: "7.63.0"

-- 
Daniel Ruggeri

[VOTE] Release httpd-2.4.39

[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.39:

[ ] +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:
sha1: e66d6bfea42254e64d3b5009f49ecc486ac46de2 *httpd-2.4.39.tar.gz
sha256: 8b95fe249f3a6c50aad3ca125eef3e02d619116cde242e1bc3c266b7b5c37c30 
*httpd-2.4.39.tar.gz


--
Daniel Ruggeri

Re: [NOTICE] Intent to T 2.4.39

[Daniel Ruggeri]

On 2019/03/23 13:43:20, Daniel Ruggeri  wrote: 
> Hi, all;
> 
>    I see there are several things ready for release in 2.4.x so I'd like
> to go ahead and get those things into our community's hands by rolling
> in the next few days.
> 
>    Please do shout loudly if you see any issues with proceeding. I'm
> thinking Tuesday or Wednesday-ish to do the T

I'll assume the absence of shouts to be a good sign :-)

I'll T in about 24 hours from now.

> 
> -- 
> Daniel Ruggeri

[NOTICE] Intent to T 2.4.39

[Daniel Ruggeri]

Hi, all;

   I see there are several things ready for release in 2.4.x so I'd like
to go ahead and get those things into our community's hands by rolling
in the next few days.

   Please do shout loudly if you see any issues with proceeding. I'm
thinking Tuesday or Wednesday-ish to do the T

-- 
Daniel Ruggeri

Re: Incomplete communications of OpenSSL 1.1.1 compatibility?

[Daniel Ruggeri]

Updated in r1854645 and published to the site. I made a slight
modification to the line I suggested yesterday to note that TLS 1.3 also
requires openssl-1.1.1, too.

I've also purged the old release from dist in r32727.

Thanks for the pointers. Have a great weekend!

-- 
Daniel Ruggeri

On 3/1/2019 6:50 AM, Daniel Ruggeri wrote:
> Hi, Bill;
> This is a good observation. I think we should add the line, "Apache
> httpd-2.4.38 or later is required in order to operate a TLS 1.3 web
> server." to the landing page. This is technically noted in the
> changelog, but the visibility of this fact should be improved because
> it is an important feature.
>
> I will update the landing page and remove .37 from dist later today or
> tomorrow morning at the latest (unless someone beats me to it).
> -- 
> Daniel Ruggeri
>
> On February 28, 2019 1:05:40 PM CST, William A Rowe Jr
>  wrote:
>
> I was just updating PR 63212 and could not point the user at a
> top-level, definitive statement that they were trying to
> accomplish something very unwise and which they should have known
> better. Apparently there are few sources of this information. From
> http://httpd.apache.org/ ...
>
>
>   Apache httpd 2.4.38 Released 2019-01-22
>
> The Apache Software Foundation and the Apache HTTP Server Project
> are pleased to announce
> <http://www.apache.org/dist/httpd/Announcement2.4.html> the
> release of version 2.4.38 of the Apache HTTP Server ("httpd").
>
> This latest release from the 2.4.x stable branch represents the
> best available version of Apache HTTP Server.
>
>
> This seems to be somewhat unhelpful from a top-level knowledge
> point of view, it doesn't indicate that they should choose 2.4.38
> over 2.4.37 for any particular reason, or that they would *need*
> to choose 2.4.38 if they wished to have a server running against
> OpenSSL 1.1.1 and later.
>
> Is there a way to improve communication of "do not use" guidance,
> outside of information at
> http://httpd.apache.org/security/vulnerabilities_24.html nested
> two-clicks deep?
>
> I do not see such guidance at http://www.apache.org/dist/httpd/
> either, the Announcement does not suggest anything. Also finding
> the offending 2.4.37 release still available for download (surely
> just an oversight.)
>
> Note PR 63212 may be entirely specific to AIX, and may be a side
> effect of build schema changes of OpenSSL 1.1.1 itself. Sorry I no
> longer have the hardware to explore such issues.
>
>

Re: Incomplete communications of OpenSSL 1.1.1 compatibility?

[Daniel Ruggeri]

Hi, Bill;
   This is a good observation. I think we should add the line, "Apache 
httpd-2.4.38 or later is required in order to operate a TLS 1.3 web server." to 
the landing page. This is technically noted in the changelog, but the 
visibility of this fact should be improved because it is an important feature.

   I will update the landing page and remove .37 from dist later today or 
tomorrow morning at the latest (unless someone beats me to it).
-- 
Daniel Ruggeri

On February 28, 2019 1:05:40 PM CST, William A Rowe Jr  
wrote:
>I was just updating PR 63212 and could not point the user at a
>top-level,
>definitive statement that they were trying to accomplish something very
>unwise and which they should have known better. Apparently there are
>few
>sources of this information. From http://httpd.apache.org/ ...
>
>
>Apache httpd 2.4.38 Released 2019-01-22
><http://httpd.apache.org/#apache-httpd-2438-released-2019-01-22>
>
>The Apache Software Foundation and the Apache HTTP Server Project are
>pleased to announce
><http://www.apache.org/dist/httpd/Announcement2.4.html> the
>release of version 2.4.38 of the Apache HTTP Server ("httpd").
>
>This latest release from the 2.4.x stable branch represents the best
>available version of Apache HTTP Server.
>
>
>This seems to be somewhat unhelpful from a top-level knowledge point of
>view, it doesn't indicate that they should choose 2.4.38 over 2.4.37
>for
>any particular reason, or that they would *need* to choose 2.4.38 if
>they
>wished to have a server running against OpenSSL 1.1.1 and later.
>
>Is there a way to improve communication of "do not use" guidance,
>outside
>of information at
>http://httpd.apache.org/security/vulnerabilities_24.html
>nested two-clicks deep?
>
>I do not see such guidance at http://www.apache.org/dist/httpd/ either,
>the
>Announcement does not suggest anything. Also finding the offending
>2.4.37
>release still available for download (surely just an oversight.)
>
>Note PR 63212 may be entirely specific to AIX, and may be a side effect
>of
>build schema changes of OpenSSL 1.1.1 itself. Sorry I no longer have
>the
>hardware to explore such issues.

Re: Anyone interested in a freelance opportunity?

[Daniel Ruggeri]

On February 22, 2019 5:03:43 AM CST, Ruediger Pluem  wrote:
>
>
>On 02/21/2019 12:46 AM, Daniel Ruggeri wrote:
>> Hi, all;
>> I was approached to see if I would be interested/willing to work on
>code to support encrypted client keys for the proxy.
>
>You mean encrypted private keys for SSL client authentication?
>You might remember that discussion from 2013 then where you took part:
>
>https://lists.apache.org/thread.html/5d4fbc62cb07a3550af4f516d007973c385389cace202d217f6b74c1@1384351589@%3Cdev.httpd.apache.org%3E

Yes, indeed. That thread is in a similar neighborhood... but is more focused on 
the idea of removing the functionality. It feels like ages ago we discussed 
that. I had all but forgotten about that thread!

My own opinion on the topic is mostly unchanged:
I agree with Joe's assertion that sometimes folks are bound to "the checklist". 
Whether that be from an auditor, security policy or some other form of edict 
passed upon the server admin team, it's their job to comply. At least in the 
large enterprises I've sampled, the response is usually: "Don't care. The 
policy says . Fix it." It'd be a shame if we cannot serve those poor 
server admins... they already have the cards stacked against them anyway. In 
the meantime since that thread, it also seems "that other web server" has added 
support for encrypted keys with passphrase coming from a file.

I don't intend to spark the debate again with this reply. We CAN do that in 
another thread as I don't think we found consensus across the project and/or 
there's not enough interest to change current inertia. After all... the doers 
will do :-) I'm just hoping the above adds context to why I personally would 
like to see the capability.

>
>
>Regards
>
>Rüdiger

Anyone interested in a freelance opportunity?

[Daniel Ruggeri]

Hi, all;
   I was approached to see if I would be interested/willing to work on code to 
support encrypted client keys for the proxy. Unfortunately, I had to pass since 
I just don't have the time, but figured I'd reach out here to see if anyone 
here has the time/expertise/interest.

   I know it's an odd thing to ask, but thought it's worth bringing up because 
I'd personally love to see this functionality :-)

Feel free to reply directly to me if you don't want to share with the list.
-- 
Daniel Ruggeri

Re: svn commit: r32075 - /dev/httpd/ /release/httpd/

[Daniel Ruggeri]

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/

[Daniel Ruggeri]

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 thi

[RESULT][VOTE] Release httpd-2.4.38 PASSED

[Daniel Ruggeri]

Hi, all;
   I am delighted to announce that the VOTE proposed in the following
thread has PASSED.
https://lists.apache.org/thread.html/a41d69a42a6352aaeee583d9671a2f3854560d7e70a115fbbbd9469a@%3Cdev.httpd.apache.org%3E


I have recorded the following votes:
PMC
jorton, jim, druggeri, rjung, ylavic

Community
Noel Butler, Dennis Clark

I thank everyone for their time in testing and verifying this latest
release. I will begin the process of promoting to the mirrors for sync.

-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.38

[Daniel Ruggeri]

On 1/20/2019 4:25 PM, Noel Butler wrote:
>
>
>>
>>   It's not just good, it's good enough!
>>
>  
> tongue in cheek here, but...
> shouldn't that be the other way around,  "It's not just good enough,
> it's good!"   :)
>  

haha - tounge in cheek indeed. The line, "It's not just good, it's good
enough" is a throwback to an old The Simpson's TV series reference.


>  
> -- 
>
> Kind Regards,
>
> Noel Butler
>
> This Email, including any attachments, may contain legally privileged
> information, therefore remains confidential and subject to copyright
> protected under international law. You may not disseminate, discuss,
> or reveal, any part, to anyone, without the authors express written
> authority to do so. If you are not the intended recipient, please
> notify the sender then delete all copies of this message including
> attachments, immediately. Confidentiality, copyright, and legal
> privilege are not waived or lost by reason of the mistaken delivery of
> this message. Only PDF  and ODF
>  documents accepted, please
> do not send proprietary formatted documents
>

Re: [VOTE] Release httpd-2.4.38

[Daniel Ruggeri]

On 2019-01-17 12:49, 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.38:
[ ] +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:
sha1: 6ee19a7b936a6ddbbf81b313c4a8b38bf232b40e *httpd-2.4.38.tar.gz
sha256:
38d0b73aa313c28065bf58faf64cec12bf7c7d5196146107df2ad07541aa26a6
*httpd-2.4.38.tar.gz


+1 from me. Tested against the following. Had an errant test failure 
related to my environment, but all good now.


  kernel:
name: Linux
release: 4.9.0-8-amd64
version: #1 SMP Debian 4.9.130-2 (2018-10-27)
machine: x86_64

  libraries:
openssl: "1.1.1a"
openldap: "2.4.47"
apr: "1.6.5"
apr-util: "1.6.1"
iconv: "1.2.2"
brotli: "1.0.7"
nghttp2: "1.35.1"
zlib: "1.2.11"
pcre: "8.42"
    libxml2: "2.9.9"
php: "5.6.40"
lua: "5.3.5"
curl: "7.63.0"

--
Daniel Ruggeri

[VOTE] Release httpd-2.4.38

[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.38:

[ ] +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:
sha1: 6ee19a7b936a6ddbbf81b313c4a8b38bf232b40e *httpd-2.4.38.tar.gz
sha256: 38d0b73aa313c28065bf58faf64cec12bf7c7d5196146107df2ad07541aa26a6 
*httpd-2.4.38.tar.gz


--
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.28

[Daniel Ruggeri]

Thank you, folks. I apologize again for the embarrassing mistake.

Will be sending along the updated vote email in a few seconds.

--
Daniel Ruggeri

On 2019-01-17 12:30, Yann Ylavic wrote:

We should at the same 2.4.x state as before the release try now, I
think the script(s) can be restarted with the correct tag/version
(2.4.38! ;) ) as if it were the first time.

On Thu, Jan 17, 2019 at 7:05 PM William A Rowe Jr  
wrote:


An aside r.e. subversion;

Just please don't do what gstein has warned us against. I've performed
the ill-advised jump-over abandoned work in the past;
   svn rm ^/httpd/mod_foo/trunk
   svn cp ^/httpd/mod_foo/trunk@123456 ^/httpd/mod_foo/trunk
attempting to drop activity between 123457 and present. Greg advised
us this turns out to do some ugly rebasing leaving a very ugly mess of
records in the underlying database. Anyone from subversion team could
give a better explanation why this is badness. This might look like
a reversion, but don't do this.

On Thu, Jan 17, 2019 at 12:00 PM Daniel Gruno  
wrote:



It's subversion, not git - we can always revert ;p

Re: svn commit: r1851557 - /httpd/httpd/branches/2.4.x/include/ap_release.h

[Daniel Ruggeri]

Yes indeed - too true! I'll be adding a failsafe for this in the scripts 
so it won't happen again.


We had a commit after the tag, so I've updated only the STATUS/CHANGES 
files to correct the errant lines. I also svn rm'ed the extra tree under 
the 2.4.28 tag.


I'll redo in about 30 more minutes - with the right version number fed 
to the machine.

--
Daniel Ruggeri

On 2019-01-17 11:51, William A Rowe Jr wrote:

One problem with scripts, they do just what they are told.

You just tagged 2.4.39 as 2.4.38.

Please revert to 2.4.38 and tag - until the tarballs are published to
vote on,
it's all development in svn history.

On Thu, Jan 17, 2019 at 11:48 AM  wrote:


Author: druggeri
Date: Thu Jan 17 17:48:40 2019
New Revision: 1851557

URL: http://svn.apache.org/viewvc?rev=1851557=rev [1]
Log:
Get ready to tag httpd 2.4.38

Modified:
    httpd/httpd/branches/2.4.x/include/ap_release.h

Modified: httpd/httpd/branches/2.4.x/include/ap_release.h
URL:


http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/ap_release.h?rev=1851557=1851556=1851557=diff

[2]


==

--- httpd/httpd/branches/2.4.x/include/ap_release.h (original)
+++ httpd/httpd/branches/2.4.x/include/ap_release.h Thu Jan 17
17:48:40 2019
@@ -44,7 +44,7 @@
 #define AP_SERVER_MAJORVERSION_NUMBER 2
 #define AP_SERVER_MINORVERSION_NUMBER 4
 #define AP_SERVER_PATCHLEVEL_NUMBER   39
-#define AP_SERVER_DEVBUILD_BOOLEAN    1
+#define AP_SERVER_DEVBUILD_BOOLEAN    0

 /* Synchronize the above with docs/manual/style/version.ent */



Links:
--
[1] http://svn.apache.org/viewvc?rev=1851557view=rev
[2]
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/ap_release.h?rev=1851557r1=1851556r2=1851557view=diff

Re: [VOTE] Release httpd-2.4.28

[Daniel Ruggeri]

On 2019-01-17 11:24, Jim Jagielski wrote:

Shouldn't this be 2.4.38??

On Jan 17, 2019, at 12:13 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.28:

[ ] +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:
sha1: 87d389fca46620ac165f8d659ba0bc8180532114 *httpd-2.4.28.tar.gz
sha256: 
216e3ee1dbd8d62f16155dff7a8aac7c6dbc6532954bec6cb8966a46f9819a23 
*httpd-2.4.28.tar.gz


--
Daniel Ruggeri


Ahh! Another typo! Please disregard this thread - will redo with the 
correct version.

--
Daniel Ruggeri

[VOTE] Release httpd-2.4.28

[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.28:

[ ] +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:
sha1: 87d389fca46620ac165f8d659ba0bc8180532114 *httpd-2.4.28.tar.gz
sha256: 216e3ee1dbd8d62f16155dff7a8aac7c6dbc6532954bec6cb8966a46f9819a23 
*httpd-2.4.28.tar.gz


--
Daniel Ruggeri

[NOTICE] Intent to T 2.4.28

[Daniel Ruggeri]

Hi, all;
   It's been a while since we've rolled a release and we've had some recent 
movement, so I'd like to propose T of 2.4.38 in the next day or two. I'll 
plan to proceed Thursday morning (US Central).
-- 
Daniel Ruggeri

Re: AH02268: Proxy client certificate callback: downstream server wanted client certificate but none are configured

[Daniel Ruggeri]

Hi, Graham;
   Yes, it should work fine... I use this kind of config a TON at $dayjob. It's 
very strange httpd would say none are configured. Is it possible the directives 
you've listed are in a different vhost? Maybe there are some bread crumbs with 
trace8 logs during start up? You could also maybe try moving all of the 
directives to the server level and see if we may have an unexpected merge 
problem.

You should at least see information about loading the key pair and what the 
client-side chain looks like from SSLProxyMachineCertificateChainFile on trace8.
-- 
Daniel Ruggeri

On January 5, 2019 8:10:20 AM CST, Graham Leggett  wrote:
>Hi all,
>
>I am trying to connect an httpd reverse proxy to a backend tomcat, and
>have this particular hop protected by a client certificate.
>
>The error I get is:
>
>[Sat Jan 05 14:02:54.252552 2019] [ssl:warn] [pid 16448:tid
>139929388369664] AH02268: Proxy client certificate callback:
>(jira.example.com:443) downstream server wanted client certificate but
>none are configured
>
>Ok, so httpd is telling me that the tomcat has requested a client
>certificate (entirely true) but httpd is not configured with a client
>certificate.
>
>Except httpd is configured with a client certificate, as follows:
>
>SSLProxyEngine on
>SSLProxyMachineCertificateFile /etc/pki/httpd/client.cert
>SSLProxyMachineCertificateChainFile /etc/pki/httpd/client.chain
>SSLProxyCACertificateFile /etc/pki/httpd/client-ca.crt
>SSLProxyVerify require
>SSLProxyVerifyDepth 3
>
>Does this functionality work in httpd v2.4.35, or is it configured
>incorrectly?
>
>(As soon as I can get this working, I would like to fix our docs to be
>clear how to do this)
>
>Regards,
>Graham
>—

Re: Time To Propose Your ApacheCon 2019 Project Summit

[Daniel Ruggeri]

We've traditionally had a day or two of content for httpd... has anyone added 
an item to the form? I cannot see the backing database/spreadsheet in the 
apachecon gsuite location...

If not, I can propose and coordinate the track... hopefully with others 
(Daniel?, Bill?) who are also on planners@, providing backup as I become busy 
at the start of the semester.
-- 
Daniel Ruggeri

On November 27, 2018 8:30:51 AM CST, Rich Bowen  wrote:
>Save the date: ApacheCon North America will be held in Las Vegas, at
>the
>Flamingo Hotel, September 9th through 12th, 2019. This is our 20th
>anniversary event, and we really want you, your project, and its
>community, to be involved.
>
>If you want to be part of making this event happen, please join the
>privately-archived planners@ mailing list by sending email to
>planners-subscr...@apachecon.com from your apache.org email address.
>
>A call for presentations will be announced soon. You should start
>giving
>some thought to what story your project wants to tell at this event,
>and
>working with your project community to craft presentations around that
>story.
>
>We will have a number of spaces for projects to conduct project
>summits,
>hackathons, or mini-conferences, lasting anywhere from a half day to
>the
>entire four days of the event.
>
>If your project, or group of several related projects, would like to
>claim an entire track (one, two, or three days of content) and craft
>that story yourselves, please propose your track or summit here:
>https://goo.gl/forms/lczPlXTmGNIsRf823
>
>The deadline for proposing a project/topic event is January 7th, (The
>first Monday of the new year) so that we can reflect these topics in
>the
>CFP.
>
>If your project holds your own standalone events(s) please consider
>co-locating with ApacheCon this coming year. We’ll help you promote
>your
>event, both as part of ApacheCon, and as its own brand. You get the
>best
>of both worlds - you get your own event, with control of your content,
>and you get to be part of a larger convention with a broader audience.
>
>This is your conference, and we are counting on you to step up and make
>it yours.
>
>Stay tuned for more information, on the planners list, and on our
>Twitter account @apachecon. And we look forward to seeing you to see
>you
>in Vegas in September!
>
>Rich Bowen, VP Conferences, and the ApacheCon Planners
>
>-- 
>@apachecon
>http://apachecon.com/
>plann...@apachecon.com

Re: Plan to add sandbox branch

[Daniel Ruggeri]

Hi, Jim;
   I'm coming up empty on a search against the Google-machine for SURVEY 
protocol. Any pointers you can share?

   I'm also curious what your thoughts are about dealing with growth of the 
worker pool beyond the control of the proxy admin. For example, if I configure 
a balancer for 10 nodes, I have an idea of tuning parameters I might set 
differently than if the number of backends is in the tens of servers.
-- 
Daniel Ruggeri

On November 27, 2018 5:23:25 AM CST, Jim Jagielski  wrote:
>In the coming week or so, I will be committing my load balance,
>load determination and discovery work to a sandbox trunk. Many
>people have asked for more info, so here we go.
>
>Basically, this new feature uses nanomsg (nng) to implement the
>SURVEY protocol between workers (nodes) and the front end server.
>The proxy server will send out MEMBERSHIP and STATUS surveys, that
>nodes can respond to; thus new nodes can automagically add themselves
>as they come up as well as remove themselves when they restart or
>shutdown via MEMBERSHIP. STATUS can be used to provide real-time
>load on each node, which will be sent via a __packed__ struct,
>ala NTP and other common usage patterns, in which 32bit fields are
>converted from endian-ness to network and back. That STATUS info can
>be used for "intelligent" load balancing and will provide some
>typical server metrics such as memory, # of cpus, etc...

Re: 2.4.38

[Daniel Ruggeri]

I like the idea. I even have a reminder in my calendar for Sunday titled "check 
if release is ready to roll" :-)

I can RM again, even.
-- 
Daniel Ruggeri

On November 7, 2018 9:15:06 AM CST, Jim Jagielski  wrote:
>Now that we have a 2.4.37 out, one in which the number of enhancements
>and fixes and feature were limited, it makes sense to consider having a
>2.4.38 release somewhat "soonish", esp considering the number of
>backports that lack only a single vote.
>
>Comments?

Re: Load balancing and load determination

[Daniel Ruggeri]

Hi, Jim J;
   I recall a while back that Jim Riggs proposed a spec for exactly this a 
while back... I think it was shared here on list and some light iteration was 
done. IIUC, he was even planning to present it at ACNA until travel plans fell 
through.

Hi, Jim R;
   Any chance you have the latest and greatest, or is the version from the list 
archives current state?


One of the things I recall *really liking* from the recommendation is letting 
the backend decide its factor based on whatever it believes is most important. 
In some servers, that may be available threads. In others it could be 
percentage of memory used. Still yet, other servers may decide based on number 
of idle GPUs on-system. I think this is roughly the same you are suggesting, 
Jim J, but I struggle to think of a universal benchmark because backends are so 
varied.
-- 
Daniel Ruggeri

On October 30, 2018 7:53:20 AM CDT, Jim Jagielski  wrote:
>As some of you know, one of my passions and area of focus is
>on the use of Apache httpd as a reverse proxy and, as such, load
>balancing, failover, etc are of vital interest to me.
>
>One topic which I have mulling over, off and on, has been the
>idea of some sort of universal load number, that could be used
>and agreed upon by web servers. Right now, the reverse proxy
>"guesses" the load on the backend servers which is OK, and
>works well enough, but it would be great if it actually "knew"
>the current loads on those servers. I already have code that
>shares basic architectural info, such as number of CPUs, available
>memory, loadavg, etc which can help, of course, but again, all
>this info can be used to *infer* the current status of those backend
>servers; it doesn't really provide what the current load actually
>*is*.
>
>So I was thinking maybe some sort of small, simple and "fast"
>benchmark which could be run by the backends as part of their
>"status" update to the front-end reverse proxy server... something
>that shows general capability at that point in time, like Hanoi or
>something similar. Or maybe some hash function. Some simple code
>that could be used to create that "universal" load number.
>
>Thoughts? Ideas? Comments? Suggestions? :)

Re: [VOTE] Release httpd-2.4.37

[Daniel Ruggeri]

On 2018-10-23 14:04, Ruediger Pluem wrote:

On 10/22/2018 04:08 PM, Daniel Ruggeri wrote:

On 2018-10-18 09:36, 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.37:
[ ] +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:
sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
sha256:
aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
*httpd-2.4.37.tar.gz


Hello, all;
   I am pleased to announce that the release vote has PASSED with the 
following recorded votes.


PMC
druggeri, jorton, jim, icing, jailletc36, ylavic, rjung

Community
Dennis Radford

I will begin the process of syncing the mirrors and preparing the 
final Announce text.


I'd like to give a big thank you for all the folks who put effort into 
creating the code for this release and the effort

spent testing this release!


Just as a side-note that may be a bug in your scripts:

http://www.apache.org/dist/httpd/CHANGES_2.4 still stops at 2.4.35 
while

http://www.apache.org/dist/httpd/CHANGES_2.4.37 is correct.
Thanks for the great scripts and RMing.

Regards

Rüdiger


Yikes! Thanks - no idea how that slipped through. I just fixed it 
manually and will triage/update the script.


--
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.37

[Daniel Ruggeri]

Hi, Cory;
   Yes, you are correct. This gets cleaned up as part of the final 
fixups in the release scripts. It's one of the things done at the last 
moment :-)


--
Daniel Ruggeri

On 2018-10-22 10:23, Cory McIntire wrote:

Just a note, the date here is Sept instead of Oct :)

http://httpd.apache.org/dev/dist/Announcement2.4.html
http://httpd.apache.org/dev/dist/Announcement2.4.txt

(I realize this might not be final version of said text.. just wanted
to mention)

Thanks
Cory McIntire
Release Manager - EasyApache
cPanel, L.L.C.


On Oct 22, 2018, at 9:08 AM, Daniel Ruggeri  
wrote:


On 2018-10-18 09:36, 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.37:
[ ] +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:
sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
sha256:
aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
*httpd-2.4.37.tar.gz


Hello, all;
  I am pleased to announce that the release vote has PASSED with the 
following recorded votes.


PMC
druggeri, jorton, jim, icing, jailletc36, ylavic, rjung

Community
Dennis Radford

I will begin the process of syncing the mirrors and preparing the 
final Announce text.


I'd like to give a big thank you for all the folks who put effort into 
creating the code for this release and the effort spent testing this 
release!


--
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.37

[Daniel Ruggeri]

On 2018-10-18 09:36, 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.37:
[ ] +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:
sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
sha256:
aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
*httpd-2.4.37.tar.gz


Hello, all;
   I am pleased to announce that the release vote has PASSED with the 
following recorded votes.


PMC
druggeri, jorton, jim, icing, jailletc36, ylavic, rjung

Community
Dennis Radford

I will begin the process of syncing the mirrors and preparing the final 
Announce text.


I'd like to give a big thank you for all the folks who put effort into 
creating the code for this release and the effort spent testing this 
release!


--
Daniel Ruggeri

Re: t/modules/http2.t: Run only if OpenSSL >= 1.0.0 is available

[Daniel Ruggeri]

On 10/21/2018 6:46 AM, Rainer Jung wrote:
> Am 18.10.2018 um 14:23 schrieb Stefan Eissing:
>>> Am 18.10.2018 um 14:12 schrieb Rainer Jung :
>>>
>>> - t/modules/http2.t fails when the server is build using OpenSSL
>>> 0.9.8zh with the "Bad plan.  You planned 52 tests..." message
>>> indicating, that h2 using TLS does not work. It happens on all
>>> platforms, but not if the client also uses OpenSSL 0.9.8zh.
>>>
>>> I don't know whether that is expected for old OpenSSL, so can not
>>> judge on criticality.
>>
>> AFAICT, correct me if I am wrong, OpenSSL 0.9.8 does not support
>> TLSv1.2 and is therefore unusable with h2. The test suite seems to be
>> unprepared for this scenario. I will remove it after the next
>> release. It is not worth fixing in its current form.
>
> I added a check agains the test suite OpenSSL version in r1844483.
>
> I have an aditional check for the server version available.
> Unfortunately I didn't find a really easy way, so here's a small
> module that one can query
> (c-modules/test_ssl_version/mod_test_ssl_version.c), mostly a
> shortened form of mod_test_ssl.c:
>
>  SNIP =
> #define HTTPD_TEST_REQUIRE_APACHE 2
>
> #if CONFIG_FOR_HTTPD_TEST
>
> 
>     
>     SetHandler test-ssl-version-lookup
>     
> 
>
> #endif
>
> #include "httpd.h"
> #include "http_config.h"
> #include "http_protocol.h"
> #include "http_log.h"
> #include "ap_config.h"
> #include "apr_optional.h"
>
> #if AP_MODULE_MAGIC_AT_LEAST(20040425, 0) /* simply include mod_ssl.h
> if using >= 2.1.0 */
>
> #include "mod_ssl.h"
>
> #else
> /* For use of < 2.0.x, inline the declaration: */
>
> APR_DECLARE_OPTIONAL_FN(char *, ssl_var_lookup,
>     (apr_pool_t *, server_rec *,
>  conn_rec *, request_rec *,
>  char *));
>
> #endif
>
> static APR_OPTIONAL_FN_TYPE(ssl_var_lookup) *var_lookup;
>
> static void import_ssl_var_lookup(void)
> {
>     var_lookup = APR_RETRIEVE_OPTIONAL_FN(ssl_var_lookup);
> }
>
> static int test_ssl_version_lookup(request_rec *r)
> {
>     char *value;
>
>     if (strcmp(r->handler, "test-ssl-version-lookup")) {
>     return DECLINED;
>     }
>
>     if (r->method_number != M_GET) {
>     return DECLINED;
>     }
>
>     if (!var_lookup) {
>     ap_rputs("ssl_var_lookup is not available", r);
>     return OK;
>     }
>
>     value = var_lookup(r->pool, r->server,
>    r->connection, r, "SSL_VERSION_LIBRARY");
>
>     if (value && *value) {
>     ap_rputs(value, r);
>     }
>     else {
>     ap_rputs("NULL", r);
>     }
>
>     return OK;
> }
>
> static void test_ssl_version_register_hooks(apr_pool_t *p)
> {
>     ap_hook_handler(test_ssl_version_lookup, NULL, NULL,
> APR_HOOK_MIDDLE);
>     ap_hook_optional_fn_retrieve(import_ssl_var_lookup,
>  NULL, NULL, APR_HOOK_MIDDLE);
> }
>
> module AP_MODULE_DECLARE_DATA test_ssl_version_module = {
>     STANDARD20_MODULE_STUFF,
>     NULL,  /* create per-dir    config structures */
>     NULL,  /* merge  per-dir    config structures */
>     NULL,  /* create per-server config structures */
>     NULL,  /* merge  per-server config structures */
>     NULL,  /* table of config file commands   */
>     test_ssl_version_register_hooks  /* register hooks     */
> };
>  SNIP =
>
> and the necessary addition to http2.t to use the module:
>
> Index: t/modules/http2.t
> ===
> --- t/modules/http2.t   (revision 1844483)
> +++ t/modules/http2.t   (working copy)
> @@ -25,6 +25,16 @@
>  my $openssl_version = Net::SSLeay::OPENSSL_VERSION_NUMBER();
>  if ($openssl_version < 0x1000) {
>  $tls_modern = 0;
> +} else {
> +    Apache::TestRequest::scheme("https");
> +    my $url = '/test_ssl_version_lookup';
> +    my $r = GET("$url");
> +    $openssl_version = $r->content;
> +    print STDOUT "OpenSSL version '$openssl_version'\n";
> +    # OpenSSL/0.9.8zh, OpenSSL/1.0.2p etc.
> +    if ($openssl_version =~ /\/0\./) {
> +    $tls_modern = 0;
> +    }
>  }
>
>  Apache::TestRequest::module("http2");
>
> What do people think? Should I apply it?
>
> Regards,
>
> Rainer

+1

-- 
Daniel Ruggeri

Re: [VOTE] Release httpd-2.4.37

[Daniel Ruggeri]

On 2018-10-18 09:36, 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.37:
[ ] +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:
sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
sha256:
aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd
*httpd-2.4.37.tar.gz


+1 from me based on the following setup

system:
  kernel:
name: Linux
release: 3.16.0-4-amd64
version: #1 SMP Debian 3.16.51-3 (2017-12-13)
machine: x86_64

  libraries:
openssl: "1.1.1"
openldap: "2.4.46"
apr: "1.6.5"
apr-util: "1.6.1"
iconv: "1.2.2"
brotli: "1.0.6"
nghttp2: "1.34.0"
zlib: "1.2.11"
pcre: "8.42"
    libxml2: "2.9.8"
php: "5.6.38"
lua: "5.3.5"
curl: "7.61.1"
--
Daniel Ruggeri

[VOTE] Release httpd-2.4.37

[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.37:

[ ] +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:
sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz
sha256: aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd 
*httpd-2.4.37.tar.gz


--
Daniel Ruggeri

Re: [NOTICE] Intent to T 2.4.37 - about 12:00 GMT tomorrow

[Daniel Ruggeri]

On 2018-10-18 07:12, Rainer Jung wrote:

Am 17.10.2018 um 13:41 schrieb Daniel Ruggeri:

Hi, all;
With the fix for detected OpenSSL 1.1.1 issues now backported to 
2.4.x, I would like to tag the next version of our venerable server 
soon.


I have already successfully completed the test suite against my 
"latest sources" docker environment and am watching for any smoke 
detected in [1]. Feeling good about this one :-)


How about roughly 24 hours from now?

[1] 
https://lists.apache.org/thread.html/48de97bd66ceabcf84a3719b36cd69274cb8c4b64d68c46696beb906@


In the meantime most of my tests finished. The two small mod_ssl
patches applied this morning were not part of the testing but seem
simple enough to understand and should pose no risk.

My testing showed:

- t/ssl/ocsp.t fails in test 2 and 3 (lines 43 and 49) when the server
is build using OpenSSL 0.9.8zh:
Can't connect to localhost:8535 (SSL connect attempt failed because of
handshake problems error:14094410:SSL routines:SSL3_READ_BYTES:sslv3
alert handshake failure)
SSL connect attempt failed because of handshake problems
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure at
/shared/build/dev/httpd/install/Bundle-ApacheTest/20180911-0.9.8zh-1/rhel7.x86_64/lib/perl5/LWP/Protocol/http.pm
 line 50.

I don't know whether that is expected for old OpenSSL, so can not
judge on criticality.

- t/modules/http2.t fails when the server is build using OpenSSL
0.9.8zh with the "Bad plan.  You planned 52 tests..." message
indicating, that h2 using TLS does not work. It happens on all
platforms, but not if the client also uses OpenSSL 0.9.8zh.

I don't know whether that is expected for old OpenSSL, so can not
judge on criticality.

- only once out of 68 runs on Solaris failure in t/modules/cgi.t test
54 in line 232. There log contents are checked and the file system is
on NFS. Might be, that this is a timing issue in the test. Not a
show-stopper for me.

- only once out of 68 runs on Solaris failure in t/ssl/proxy.t test
106 in line 131. /eat_post responds with a proxy error (502) instead
of 200 with the posted content length as the response body. Need to
investigate but would also say not a show-stopper, because only on
Solaris and only once.

- some crashes on Solaris when building the server statically linked.
Only with event MPM and looks like always at the end of a process
lifetime, typically during shutdown. Maybe a problem with duplicate
OpenSSL unloading/cleanup (apr-util plus mod_ssl). I think its a known
problem, but no fix yet available. Since it should not happen to
processes which are in use I would say it is more of an annoyance and
not a show-stopper.

Regards,

Rainer


Thank you so much for the thorough testing. I see that the H2 failure 
case makes sense based on feedback. I also suspect there is a strong 
lead on the ocsp case. I'm also pleased to see the backports have 
already made it into 2.4.x so I think we're good to go.


--
Daniel Ruggeri

Re: [NOTICE] Intent to T 2.4.37 - about 12:00 GMT tomorrow

[Daniel Ruggeri]

On 2018-10-17 13:13, Dennis Clarke wrote:

On 10/17/2018 07:41 AM, Daniel Ruggeri wrote:

Hi, all;
With the fix for detected OpenSSL 1.1.1 issues now backported to 
2.4.x, I would like to tag the next version of our venerable server 
soon.


I have already successfully completed the test suite against my 
"latest sources" docker environment and am watching for any smoke 
detected in [1]. Feeling good about this one :-)


How about roughly 24 hours from now?



Can we get a tarball at https://dist.apache.org/repos/dist/dev/httpd/ ?

Dennis


Hi, Dennis;
   Yes, of course. That gets pushed shortly after the tag occurs. An 
email will be sent to this list immediately after. I anticipate that it 
will be there no later than 13:00 GMT tomorrow.


If you're interested in the details, feel free to check out the release 
documentation here:

http://httpd.apache.org/dev/release.html

--
Daniel Ruggeri

Re: [Discussion] Limit the scope of 2.4.x patches until 2.4.next is released?

[Daniel Ruggeri]

I like the idea. It took a bit of ruminating to get there, but the thought of 
shipping new features in odds and fixes/stabilizations in evens (or something 
along those lines) feels comfortable. I would personally prefer a semver 
release style where we burn minors often-ish, but haven't been able to comment 
on Eric's document yet to socialize the thoughts. This is a good compromise in 
the meantime.

Of course... an important part of making that work is clarifying and 
documenting the practice with our user community. The other part is having RMs 
ready/willing to do their thing more frequently. Our unpredictable and often 
long release cycle could cause features/fixes to get "locked up" in the branch 
if we don't have a conduit to get those bits to the community. I'm willing to 
commit cycles there, but my hope is that the automation reduces the barrier to 
entry for an RM and we can add to the list of ready volunteers. Indeed, I was 
encouraging jchampion at ACNA to toss his hat in the ring as an RM... here's to 
hoping :-)
-- 
Daniel Ruggeri

On October 15, 2018 9:10:13 AM CDT, William A Rowe Jr  
wrote:
>Like my beg for getting us to the 2.4.35 release tag, I'd like to
>propose
>we keep patches to branches/2.4.x/ generally within the scope of
>straightening out the remaining quirks related to the OpenSSL 1.1.1 API
>and
>library behavior changes (and similar corrections for any alternate
>library
>implementations such as LibreSSL or BoringSSL.)
>
>This isn't a vote per se... just an ask whether we collectively want to
>defer all potentially disruptive changes for a release following
>2.4.next.
>We can certainly resume with that next release on an expedited basis,
>within a month or few (as opposed to waiting 6 months as has been
>typical.)
>
>It appears that dropping in OpenSSL 1.1.1 into a previously working
>httpd
>built against 1.1.0 is not the "plug and play" replacement that the
>OpenSSL
>team originally envisioned, and deliberately building any previous
>release
>of httpd against 1.1.1 is similarly broken.
>
>Thoughts? Other concerns?

[NOTICE] Intent to T 2.4.37 - about 12:00 GMT tomorrow

[Daniel Ruggeri]

Hi, all;
   With the fix for detected OpenSSL 1.1.1 issues now backported to 2.4.x, I 
would like to tag the next version of our venerable server soon.

   I have already successfully completed the test suite against my "latest 
sources" docker environment and am watching for any smoke detected in [1]. 
Feeling good about this one :-)

   How about roughly 24 hours from now?

[1] 
https://lists.apache.org/thread.html/48de97bd66ceabcf84a3719b36cd69274cb8c4b64d68c46696beb906@
-- 
Daniel Ruggeri

Re: svn commit: r1844047 - in /httpd/httpd/branches/2.4.x: ./ STATUS modules/ssl/ssl_engine_io.c

[Daniel Ruggeri]

Thank you so much for your thorough work.

One of these days I'd love to hear all about your testing setup. It would so 
cool to run something similar on our buildbot!
-- 
Daniel Ruggeri

On October 17, 2018 3:01:11 AM CDT, Rainer Jung  wrote:
>Thanks.
>
>I'm doing new builds now for a bunch of OpenSSL versions and shared
>plus 
>static linking (but only the reallyall module set). Then I will run the
>
>test suite, combining each with a bunch of OpenSSL versions used in the
>
>client (perl modules).
>
>I guess those runs will take until tomorrow.
>
>Regards,
>
>Rainer
>
>Am 16.10.2018 um 22:24 schrieb drugg...@apache.org:
>> Author: druggeri
>> Date: Tue Oct 16 20:24:23 2018
>> New Revision: 1844047
>> 
>> URL: http://svn.apache.org/viewvc?rev=1844047=rev
>> Log:
>>*) mod_ssl: Handle SSL_read() return code 0 similarly to <0. It is
>needed
>>when using OpenSSL 1.1.1 and should not harm for
>versions before
>>1.1.1.
>>Without the patch for 1.1.1 a 0 byte read no longer
>results in
>>EAGAIN but instead in APR_EOF which leads to HTTP/2
>failures.
>>For the changelog: Fix HTTP/2 failures when using
>OpenSSL 1.1.1.
>>   trunk patch: http://svn.apache.org/r1843954
>>   2.4.x patch: svn merge -c 1843954 ^/httpd/httpd/trunk .
>>   +1: rjung, druggeri, rpluem
>> 
>> 
>> Modified:
>>  httpd/httpd/branches/2.4.x/   (props changed)
>>  httpd/httpd/branches/2.4.x/STATUS
>>  httpd/httpd/branches/2.4.x/modules/ssl/ssl_engine_io.c
>> 
>> Propchange: httpd/httpd/branches/2.4.x/
>>
>--
>> --- svn:mergeinfo (original)
>> +++ svn:mergeinfo Tue Oct 16 20:24:23 2018
>> @@ -8,4 +8,4 @@
>>   /httpd/httpd/branches/trunk-md:1804087-1804529
>>   /httpd/httpd/branches/trunk-override-index:1793921-1793931
>>   /httpd/httpd/branches/wombat-integration:723609-723841
>>
>-/httpd/httpd/trunk:1200475,1200478,1200482,1200491,1200496,1200513,1200550,1200556,1200580,1200605,1200612,1200614,1200639,1200646,1200656,1200667,1200679,1200699,1200702,1200955,1200957,1200961,1200963,1200968,1200975,1200977,1201032,1201042,120,1201194,1201198,1201202,1201443,1201450,1201460,1201956,1202236,1202453,1202456,1202886,1203400,1203491,1203632,1203714,1203859,1203980,1204630,1204968,1204990,1205061,1205075,1205379,1205885,1206291,1206472,1206587,1206850,1206940,1206978,1207719,1208753,1208835,1209053,1209085,1209417,1209432,1209461,1209601,1209603,1209618,1209623,1209741,1209754,1209766,1209776,1209797-1209798,1209811-1209812,1209814,1209908,1209910,1209913,1209916-1209917,1209947,1209952,1210067,1210080,1210120,1210124,1210130,1210148,1210219,1210221,1210252,1210284,1210336,1210378,1210725,1210892,1210951,1210954,1211351-1211352,1211364,1211490,1211495,1211528,1211663,1211680,1212872,1212883,1213338,1213380-1213381,1213391,1213399,1213567,1214003,1214005,1214015,12
>>  
>15514,1220462,1220467,1220493,1220524,1220570,1220768,1220794,1220826,1220846,1221205,1221292,1222335,1222370,1222473,1222915,1222917,1222921,1222930,1223048,1225060,1225197-1225199,1225223,1225380,1225476,1225478,1225791,1225795-1225796,1226339,1226375,1227910,1228700,1228816,1229024,1229059,1229099,1229116,1229134,1229136,1229930,1230286,1231255,1231257,1231442,1231446,1231508,1231510,1231518,1232575,1232594,1232630,1232838,1234180,1234297,1234479,1234511,1234565,1234574,1234642-1234643,1234876,1234899,1235019,1236122,1236701,1237407,1238545,1238768,1239029-1239030,1239071,1239565,1240315,1240470,1240778,1241069,1241071,1242089,1242798,1242967,1243176,1243246,1243797,1243799,1244211,1245717,1290823,1290835,1291819-1291820,1291834,1291840,1292043,1293405,1293534-1293535,1293658,1293678,1293708,1294306,1294349,1294356,1294358,1294372,1294471,1297560,1299718,1299786,1300766,130,1301725,1302444,1302483,1302653,1302665,1302674,1303201,1303435,1303827,1304087,1304874-1304875,1305167
>>  
>,1305586,1306350,1306409,1306426,1306841,1307790,1308327,1308459,1309536,1309567,1311468,1324760,1325218,1325227,1325250,1325265,1325275,1325632,1325724,1326980,1326984,1326991,1327689,1328325-1328326,1328339,1328345,1328950,1330189,1330964,1331110,1331115,1331942,1331977,1332378,1333969,1334343,1335882,1337344,1341905-1341906,1341913,1341930,1342065,1343085,1343087,1343094,1343099,1343109,1343935,1344712,1345147,1345319,1345329,1346905,1347980,1348036,1348653,1348656,1348660,1349905,1351012-1351020,1351071-1351072,1351074,1351737,1352047,1352534,1352909-1352912,1357685,1358061,1359057,1359881,1359884,1361153,1361298,1361766,1361773,1361778,1361784,1361791-1361792,1361801,1361803,1362020,1362538,1362707,13630

Re: [VOTE] Release httpd-2.4.36

[Daniel Ruggeri]

Hi, all;
   As a result of testing and further analysis of this release, I am calling 
this release dead on the vine and shall not pursue publishing it. We have -1 
votes based on the recently discovered OpenSSL 1.1.1 behavior change [1].

Although this tag shall not become a release, I'd like to thank all testers and 
those who have put effort into getting us to this point as well as catching an 
error that could impact our users. I consider this a victory :-)

I will follow up with another proposal to T when we resolve the issue.

Cheers!

[1] 
https://lists.apache.org/thread.html/cff9db75d9e281f116382f090b3079dedc2c9842192d213ae4948e15@%3Cdev.httpd.apache.org%3E
-- 
Daniel Ruggeri

On 2018/10/10 19:18:45, 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.36:
> [ ] +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:
> sha1: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz
> sha256: ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288 
> *httpd-2.4.36.tar.gz
> 
> -- 
> Daniel Ruggeri
> 

Re: [VOTE] Release httpd-2.4.36

[Daniel Ruggeri]

Hi, Helmut;
   Note that the vote may run longer than 72 hours as 72 is the minimum. As it 
stands now, we have more than 3 binding +1 votes, but I am waiting for closure 
on the conversation on-list about the tests with reported H2/TLS 1.3 failures. 
Since this is one of the primary features of this release, I want to be sure 
the topic gets due attention.
-- 
Daniel Ruggeri

On October 14, 2018 4:44:04 PM CDT, "Helmut K. C. Tessarek" 
 wrote:
>On 2018-10-10 15:18, 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.36:
>> [ ] +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:
>> sha1: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz
>> sha256:
>ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288
>> *httpd-2.4.36.tar.gz
>
>72h have passed, so what is the outcome of the vote?
>
>
>-- 
>regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
>Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
>
>/*
>   Thou shalt not follow the NULL pointer for chaos and madness
>   await thee at its end.
>*/

Re: [VOTE] Release httpd-2.4.36

[Daniel Ruggeri]

+1 from me (talking to myself).

Test environment follows. I observe only one failure of the test suite
(mentioned elsewhere) - it seems only to apply w/ OpenSSL 1.1.1 and H2.

system:
  kernel:
    name: Linux
    release: 3.16.0-4-amd64
    version: #1 SMP Debian 3.16.51-3 (2017-12-13)
    machine: x86_64

  libraries:
    openssl: "1.1.1"
    openldap: "2.4.46"
    apr: "1.6.5"
    apr-util: "1.6.1"
    iconv: "1.2.2"
    brotli: "1.0.6"
    nghttp2: "1.34.0"
    zlib: "1.2.11"
    pcre: "8.42"
    libxml2: "2.9.8"
    php: "5.6.38"
    lua: "5.3.5"
    curl: "7.61.1"

-- 
Daniel Ruggeri

On 10/10/2018 2:18 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.36:
> [ ] +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:
> sha1: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz
> sha256:
> ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288
> *httpd-2.4.36.tar.gz
>

Re: NOTICE: Intent to T 2.4.36

[Daniel Ruggeri]

On 2018-10-10 14:01, William A Rowe Jr wrote:

On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski  wrote:


I thought the whole intent for a quick 2.4.36 was for TLSv1.3
support.

If that's not ready for prime time, then why a release??


AIUI, it isn't that httpd isn't ready for release, or even httpd-test
framework.
Until all the upstream CPAN modules behave reasonably with openssl
1.1.1
we will continue to see odd test results.

It was my hope we would push this out as 2.5.1-alpha, as now synced
with 2.4.x branch, and let the eager early adopters help us uncover
any
unforeseen issues. Think we have a handle on, and have addressed
the anticipated issues.


Right, my understanding is that this is more around the test suite and 
how it does the testing rather than the project itself. If that's not 
the case, and httpd itself isn't ready, I'm OK with aborting the release 
process.


--
Daniel Ruggeri

[VOTE] Release httpd-2.4.36

[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.36:

[ ] +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:
sha1: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz
sha256: ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288 
*httpd-2.4.36.tar.gz


--
Daniel Ruggeri

Re: NOTICE: Intent to T 2.4.36

[Daniel Ruggeri]

On 2018-10-10 07:30, Joe Orton wrote:

On Tue, Oct 09, 2018 at 03:29:49PM -0500, Daniel Ruggeri wrote:

Hi, all;
   I ran through my usual testing routine, this time with OpenSSL 
1.1.1, but
found several test failures. In the past, these issues have been 
isolated to
my environment so I just wanted to drop a line to see if anyone has 
run the
test suite against 2.4.x lately and can corroborate this result? If 
not, I

can debug my environment.


TLSv1.3 testing is still a mess with OpenSSL 1.1.1, sorry.  I have
updated the test suite just now to disable TLSv1.3 testing for most
people.  We need updates to Net::SSLeay (the latest upstream has the
patch) and IO::Socket::SSL, but the latter is not patched upstream, so 
I

can't make an accurate test for that yet.

At worst, forcibly testing with:

  ./t/TEST -sslproto 'all -TLSv1.2'

should now be possible.

(If using an existing check-out of the test suite don't forget to 
re-run

"make" before running ./t/TEST -conf to regenerate the config...)

Let me know if that's not made any difference for you.

I don't know why t/modules/http2.t is failing but I see that here too.


Thanks Joe and Bill.

Yep, when flipping back over to OpenSSL 1.1.0i, everything works A-OK. 
Even the H2 failure irons itself out. It's a bummer to hear TLS 1.3 
testing isn't up to snuff with this being the major feature of the 
release.


I also just wiped the environment, recompiled everything from scratch 
(same versions noted below) and reran the tests with the latest test 
framework and see that the recent changes to the framework leave only 
the failing h2 test (which doesn't happen w/ 1.1.0i). So... I think it 
was indeed localized to the test framework.


I'm also happy to see the H2 EOS fix in, too!

So... I think I'm content with the results and am ready to T!



Regards, Joe




Test Summary Report
---
t/modules/http2.t (Wstat: 0 Tests: 24 Failed: 0)
  Parse errors: Bad plan.  You planned 52 tests but ran 24.
t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2)
  Failed tests:  3-4
t/ssl/basicauth.t (Wstat: 0 Tests: 4 Failed: 2)
  Failed tests:  2-3
t/ssl/env.t   (Wstat: 0 Tests: 30 Failed: 15)
  Failed tests:  16-30
t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4)
  Failed tests:  1-4
t/ssl/fakeauth.t  (Wstat: 0 Tests: 3 Failed: 2)
  Failed tests:  2-3
t/ssl/ocsp.t  (Wstat: 0 Tests: 3 Failed: 1)
  Failed test:  3
t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 3)
  Failed tests:  2, 5, 9
t/ssl/varlookup.t (Wstat: 0 Tests: 83 Failed: 83)
  Failed tests:  1-83
t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1)
  Failed test:  2
Files=186, Tests=8857, 101 wallclock secs ( 1.86 usr  0.28 sys + 48.46 
cusr

11.08 csys = 61.68 CPU)


Versions at play were:
system:
  kernel:
name: Linux
release: 3.16.0-4-amd64
version: #1 SMP Debian 3.16.51-3 (2017-12-13)
machine: x86_64

  libraries:
openssl: "1.1.1"
openldap: "2.4.46"
apr: "1.6.5"
apr-util: "1.6.1"
iconv: "1.2.2"
brotli: "1.0.6"
nghttp2: "1.34.0"
zlib: "1.2.11"
pcre: "8.42"
libxml2: "2.9.8"
    php: "5.6.38"
    lua: "5.3.5"
curl: "7.61.1"


Anything look obviously crazy/wrong?

--
Daniel Ruggeri

On 2018-10-09 06:36, Daniel Ruggeri wrote:
> Hi, all;
>  Barring any major disagreement in the next several hours, I intend to
> T our next version later today or early tomorrow.
>
> Hooray for TLS 1.3!
> --
> Daniel Ruggeri


--
Daniel Ruggeri

Re: NOTICE: Intent to T 2.4.36

[Daniel Ruggeri]

Hi, all;
   I ran through my usual testing routine, this time with OpenSSL 1.1.1, 
but found several test failures. In the past, these issues have been 
isolated to my environment so I just wanted to drop a line to see if 
anyone has run the test suite against 2.4.x lately and can corroborate 
this result? If not, I can debug my environment.


Test Summary Report
---
t/modules/http2.t (Wstat: 0 Tests: 24 Failed: 0)
  Parse errors: Bad plan.  You planned 52 tests but ran 24.
t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2)
  Failed tests:  3-4
t/ssl/basicauth.t (Wstat: 0 Tests: 4 Failed: 2)
  Failed tests:  2-3
t/ssl/env.t   (Wstat: 0 Tests: 30 Failed: 15)
  Failed tests:  16-30
t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4)
  Failed tests:  1-4
t/ssl/fakeauth.t  (Wstat: 0 Tests: 3 Failed: 2)
  Failed tests:  2-3
t/ssl/ocsp.t  (Wstat: 0 Tests: 3 Failed: 1)
  Failed test:  3
t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 3)
  Failed tests:  2, 5, 9
t/ssl/varlookup.t (Wstat: 0 Tests: 83 Failed: 83)
  Failed tests:  1-83
t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1)
  Failed test:  2
Files=186, Tests=8857, 101 wallclock secs ( 1.86 usr  0.28 sys + 48.46 
cusr 11.08 csys = 61.68 CPU)



Versions at play were:
system:
  kernel:
name: Linux
release: 3.16.0-4-amd64
version: #1 SMP Debian 3.16.51-3 (2017-12-13)
machine: x86_64

  libraries:
openssl: "1.1.1"
openldap: "2.4.46"
apr: "1.6.5"
apr-util: "1.6.1"
iconv: "1.2.2"
brotli: "1.0.6"
nghttp2: "1.34.0"
zlib: "1.2.11"
pcre: "8.42"
libxml2: "2.9.8"
    php: "5.6.38"
lua: "5.3.5"
curl: "7.61.1"


Anything look obviously crazy/wrong?

--
Daniel Ruggeri

On 2018-10-09 06:36, Daniel Ruggeri wrote:

Hi, all;
 Barring any major disagreement in the next several hours, I intend to
T our next version later today or early tomorrow.

Hooray for TLS 1.3!
--
Daniel Ruggeri

NOTICE: Intent to T 2.4.36

[Daniel Ruggeri]

Hi, all;
  Barring any major disagreement in the next several hours, I intend to T our 
next version later today or early tomorrow.

Hooray for TLS 1.3!
-- 
Daniel Ruggeri

Re: Wherefor 2.4.36?

[Daniel Ruggeri]

Actually, I'm glad you asked. I committed after 2.4.35 to T 2.4.36 soon 
after. I'm happy to do that ASAP if there are no objections.

What say you, fellow devs? How about next week?
-- 
Daniel Ruggeri

On October 6, 2018 7:53:58 PM CDT, Michael-Fever  wrote:
>
>Aww, all I care about is getting 2.4.36 going so I can say I have TLS
>1.3
>supported with my h2.  LOL, no but seriously, is 2.4.36 stable enough
>to be
>using?
>
>
>
>--
>Sent from:
>http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html

Re: Announce missing - in moderation?

[Daniel Ruggeri]

Hi, Bill;

   Sure. I've updated the scripts to set the reply-to address and also
fired a message off to ann@a.o to wrap it up. I didn't change the date
of the announcement, so hopefully that won't pose a problem.

   Later I'll commit a change to just send separate emails instead of a
multi-to message since that seems like the easiest approach.

-- 
Daniel Ruggeri

On 9/28/2018 9:13 PM, William A Rowe Jr wrote:
> Sebb thank you for your analysis!
>
> Two issues; one, the reply-to field of security announcements was set
> to security@, and this is in direct contravention of Apache policy.
> Security@ is exclusively for reporting undisclosed vulnerabilities,
> and all other traffic is ignored. This group of email addresses must
> never be shared without context and usage guidance. Please, never do
> that again.
>
> Two, this announce is still not published to ann@a.o. What is the next
> step to cause this to happen? Daniel, could you use a conventional
> mail agent to wrap this cycle up?
>
>
>
> On Wed, Sep 26, 2018, 18:40 sebb  <mailto:seb...@gmail.com>> wrote:
>
> Also just realised the Message-Id is missing.
>
> Some servers (e.g. GMail) may add it; if they don't it can causes
> issues for mod_mbox and possibly other archivers.
> It also causes problems for mail threading.
> And if the mail is sent to multiple destinations, each generated
> Message-Id will be different.
>
> On 26 September 2018 at 22:04, Noel Butler  <mailto:noel.but...@ausics.net>> wrote:
>
> On 27/09/2018 05:37, sebb AT ASF wrote:
>
>>
>> I don't know if this is relevant, but the messages don't have
>> a Date: header.
>  
> A  this would be because Daniel used curl to send them
> rather than a sane method :)
>  
>  
>  
>> Also some of the received headers look odd:
>>
>> Received: from Announcement.txt (IP redacted)
>> by mailrelay1-lw-us.apache.org
>> <http://mailrelay1-lw-us.apache.org> (ASF Mail Server at
>> mailrelay1-lw-us.apache.org
>> <http://mailrelay1-lw-us.apache.org>) with ESMTPSA id redacted
>> for > <mailto:annou...@httpd.apache.org>>; Sat, 22 Sep 2018
>> 11:41:35 + (UTC)
>>
>> and
>>
>> Received: from CVE-2018-11763-h2-dos-by-settings.txt (IP
>> redacted)
>> by mailrelay2-lw-us.apache.org
>> <http://mailrelay2-lw-us.apache.org> (ASF Mail Server at
>> mailrelay2-lw-us.apache.org
>> <http://mailrelay2-lw-us.apache.org>) with ESMTPSA id redacted
>> for > <mailto:annou...@httpd.apache.org>>; Sat, 22 Sep 2018
>> 11:41:38 + (UTC)
>>
> -- 
>
> Kind Regards,
>
> Noel Butler
>
> This Email, including any attachments, may contain legally
> privileged information, therefore remains confidential and
> subject to copyright protected under international law. You
> may not disseminate, discuss, or reveal, any part, to anyone,
> without the authors express written authority to do so. If you
> are not the intended recipient, please notify the sender then
> delete all copies of this message including attachments,
> immediately. Confidentiality, copyright, and legal privilege
> are not waived or lost by reason of the mistaken delivery of
> this message. Only PDF <http://www.adobe.com/> and ODF
> <http://en.wikipedia.org/wiki/OpenDocument> documents
> accepted, please do not send proprietary formatted documents
>
>

Re: Announce missing - in moderation?

[Daniel Ruggeri]

FWIW, this was a straight forward multi-To field email message addressed to 
both lists. If there is a way I can improve the announce/release automation, I 
am happy to do so. Maybe a better way is to send multiple messages?
-- 
Daniel Ruggeri

On September 25, 2018 7:12:25 PM EDT, William A Rowe Jr  
wrote:
>Agreed it was published to ann@httpd.a.o, likely Jim's approval.
>
> It has not arrived at a...@apache.org.
>
>Sebb, can you shed any light on this moderation issue?
>
>
>
>On Tue, Sep 25, 2018, 12:29 Jim Jagielski  wrote:
>
>> FWIW, I just saw a mod request for *an* announcement and approved it
>>
>> On Sep 25, 2018, at 12:19 PM, Private LIst Moderation <
>> mod-priv...@gsuite.cloud.apache.org> wrote:
>>
>> Hi Daniel,
>>
>> I've looked in the moderation queue and did not find the announce@
>> moderation email.
>>
>> Craig
>>
>> On Sep 25, 2018, at 7:00 AM, Daniel Ruggeri 
>wrote:
>>
>> Infra points out it's easier to just resend than to dig out the
>message
>> they found on the server. I've sent again - receiving these
>confirmations:
>>
>> < 235 2.7.0 Authentication successful
>>
>> MAIL FROM: SIZE=2919
>>
>> < 250 2.1.0 Ok
>>
>> RCPT TO:
>>
>> < 250 2.1.5 Ok
>>
>> DATA
>>
>> < 354 End data with .
>> } [data not shown]
>> * We are completely uploaded and fine
>> < 250 2.0.0 Ok: queued as EB77F2332
>>
>> < 235 2.7.0 Authentication successful
>>
>> MAIL FROM: SIZE=874
>>
>> < 250 2.1.0 Ok
>>
>> RCPT TO:
>>
>> < 250 2.1.5 Ok
>>
>> DATA
>>
>> < 354 End data with .
>> } [data not shown]
>> * We are completely uploaded and fine
>> < 250 2.0.0 Ok: queued as 9B4B1E1B
>>
>> I've also added Craig here as he was unable to find the message sent
>to
>> announce@a.o - with luck, these won't vanish, but at least this time
>I
>> have the message IDs...
>> --
>> Daniel Ruggeri
>>
>> On 2018-09-24 16:59, Daniel Ruggeri wrote:
>>
>> Yes, I sent via curl (true story, you can send email with curl)
>> directly to the relay service and authenticated with my ASF
>> credentials. I had checked in with Infra here at ACNA and they saw
>> *something* that looked like my message. I'll check in with them
>> again.
>> Thanks, folks
>> --
>> Daniel Ruggeri
>> On September 24, 2018 3:07:00 PM EDT, William A Rowe Jr
>>  wrote:
>>
>> I'm seeing no announce@httpd moderation request. (I am not an
>> annou...@apache.org moderator.)
>> Did you send from your @apache.org [1] avail-id through the ASF
>> server? It would
>> be rejected for non-apache and for mismatched SPF records.
>> On Mon, Sep 24, 2018 at 9:16 AM Daniel Ruggeri 
>> wrote:
>>
>> Hi, all;
>> I sent the announce message for 2.4.35, but haven't received it
>> myself. I didn't get errors sending that I am aware of. Perhaps it
>> is in moderation? If not, I can check in with infra to see if
>> mail-relay.a.o ate it.
>> Thanks
>> --
>> Daniel Ruggeri
>>
>> Links:
>> --
>> [1] http://apache.org
>>
>>
>>
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> c...@apache.org http://db.apache.org/jdo
>>
>>
>>