Broken: apache/httpd#1938 (2.4.x - 2dcc0bb)

[Travis CI]

Build Update for apache/httpd
-

Build: #1938
Status: Broken

Duration: 19 mins and 11 secs
Commit: 2dcc0bb (2.4.x)
Author: Stefan Eissing
Message: Merge of /httpd/httpd/trunk:r1893399

  *) mod_md: when MDMessageCmd for a 'challenge-setup::'
 fails (!= 0 exit), the renewal process is aborted and an error is
 reported for the MDomain. This provides scripts that distribute
 information in a cluster to abort early with bothering an ACME
 server to validate a dns name that will not work. The common
 retry logic will make another attempt in the future, as with
 other failures.
 Fixed a bug when adding private key specs to an already working
 MDomain, see .



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1893400 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/22382addd193...2dcc0bb4fe42

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


--

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

Broken: apache/httpd#1937 (trunk - 00e2ca5)

[Travis CI]

Build Update for apache/httpd
-

Build: #1937
Status: Broken

Duration: 11 mins and 56 secs
Commit: 00e2ca5 (trunk)
Author: Stefan Eissing
Message:   *) mod_md: when MDMessageCmd for a 'challenge-setup::'
 fails (!= 0 exit), the renewal process is aborted and an error is
 reported for the MDomain. This provides scripts that distribute
 information in a cluster to abort early with bothering an ACME
 server to validate a dns name that will not work. The common
 retry logic will make another attempt in the future, as with
 other failures.
 Fixed a bug when adding private key specs to an already working
 MDomain, see .



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

View the changeset: 
https://github.com/apache/httpd/compare/44abd7180eba...00e2ca574f6e

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


--

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

Re: [httpd-site] branch main updated: publishing release httpd-2.4.49

[Ruediger Pluem]

On 9/17/21 11:29 AM, ste...@eissing.org wrote:
> 
> 
>> Am 17.09.2021 um 11:20 schrieb ste...@eissing.org:
>>
>>
>>
>>> Am 17.09.2021 um 11:18 schrieb Ruediger Pluem :
>>>
>>>
>>>
>>> On 9/17/21 9:36 AM, ste...@eissing.org wrote:


> Am 17.09.2021 um 08:54 schrieb Ruediger Pluem :
>
>
>
> On 9/16/21 10:12 PM, ste...@eissing.org wrote:
>>
>>
>>> Am 16.09.2021 um 21:44 schrieb Ruediger Pluem :
>>>
>>>
>>>
>>> On 9/16/21 7:13 PM, Eric Covener wrote:
 On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox  wrote:
>
> Hi; at the moment the ASF customisation to the tool is tracked in my 
> github fork along with issues. There's no specific place to discuss 
> it other than secur...@apache.org.  That's all just because there's 
> only me having worked on it.
>
> There are going to be some big changes needed to the tool and running 
> instance in the coming months to support the new CVE Project v5.0 
> JSON schema, as that is required for more of the future CVE project 
> automation (such as live submission to their database), so that will 
> likely take up all the time I can personally spend updating the tool 
> in the near future.

 For the sake of discussion/argument: Do we want/need to reproduce this
 information on the website or is linking to the changelog sufficient?
 We lose our pseudo-scoring and the range of affected versions.  We
 could bake them into our changelog-entry authoring/review.
>>>
>>> I like to keep our current vulnerabilities page. On the contrary. I 
>>> would like to see it extended with the revision numbers that
>>> fixed the actual issue.
>>
>> +1. makes sense to me.
>>
>>> I like the vulnerabilities page we and Tomcat has very much as it eases 
>>> the search and doesn't force me to got through changelogs
>>> or other information not that quickly available.
>>
>> Given the answer by Mark on extensibility of the cveprocess site, we 
>> should make a solution based on our own pmc repository.
>>
>> What makes most sense to me is to copy the CVE-JSON to the pmc repro, 
>> when a CVE is "ready" (from our side) for a release. Let readiness.sh 
>> check on that and also verify that all fields we need are in there.
>>
>> Since we no longer need to have unreleased version numbers, we can make 
>> a directory like "2.4.50" and add them there. The release scripts can 
>> then pick them up, put the info in the CHANGES and add them to the site. 
>> With an added "timeline" entry for date and release number.
>
> I understand that there is no need to burn version numbers any longer 
> with the new release scripts, but why would a failed release
> matter to this process?


 One thing that was nagging me in the release scripts: the steps run over 
 some time (up to a week possibly), and assume that nothing changes in the 
 pmc repository during this time. So the scripts might pick up a "ready" 
 CVE that is not part of the tarballs.

 I was thinking of create a version directory to fix that, but that seems 
 overkill on reconsidering it. I am not thinking that the release
>>>
>>> I am a little bit confused with this and the following sentence.
>>> Do you want to say I am *not* thinking or I am thinking?
>>
>> Sorry, not enough coffee. "I am *now* thinking..."
> 
> To spell it out more clearly:
> 
> - when a CVE is considered "ready" by us, but not set 
>   to READY in the cveprocess (it is not released yet), 
>   we manually copy the CVE-JSON from the site into 
>   "pmc/SECURITY/ - tools/readiness.sh checks that file for completeness
> - dev-tools/release/r0-make-candidate.sh copies those 
>   files into "pmc/SECURITY/release-" dir.
> - cancelling a candidate would remove that dir again
> - dev-tools/r4-stage-release.sh takes the CVEs from that
>   dir and adds content to CHANGES, copies to site etc.
> 
> This means that when CVEs become ready after a candidate is
> built, it won't slip accidentally into the announcements
> or CHANGES.
> 
> There is the one manual step of copying, but the rest is
> handled by scripts.

Thanks for the clarification. +1 to the steps above.

Regards

Rüdiger

Re: [httpd-site] branch main updated: publishing release httpd-2.4.49

[ste...@eissing.org]

> Am 17.09.2021 um 11:20 schrieb ste...@eissing.org:
> 
> 
> 
>> Am 17.09.2021 um 11:18 schrieb Ruediger Pluem :
>> 
>> 
>> 
>> On 9/17/21 9:36 AM, ste...@eissing.org wrote:
>>> 
>>> 
 Am 17.09.2021 um 08:54 schrieb Ruediger Pluem :
 
 
 
 On 9/16/21 10:12 PM, ste...@eissing.org wrote:
> 
> 
>> Am 16.09.2021 um 21:44 schrieb Ruediger Pluem :
>> 
>> 
>> 
>> On 9/16/21 7:13 PM, Eric Covener wrote:
>>> On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox  wrote:
 
 Hi; at the moment the ASF customisation to the tool is tracked in my 
 github fork along with issues. There's no specific place to discuss it 
 other than secur...@apache.org.  That's all just because there's only 
 me having worked on it.
 
 There are going to be some big changes needed to the tool and running 
 instance in the coming months to support the new CVE Project v5.0 JSON 
 schema, as that is required for more of the future CVE project 
 automation (such as live submission to their database), so that will 
 likely take up all the time I can personally spend updating the tool 
 in the near future.
>>> 
>>> For the sake of discussion/argument: Do we want/need to reproduce this
>>> information on the website or is linking to the changelog sufficient?
>>> We lose our pseudo-scoring and the range of affected versions.  We
>>> could bake them into our changelog-entry authoring/review.
>> 
>> I like to keep our current vulnerabilities page. On the contrary. I 
>> would like to see it extended with the revision numbers that
>> fixed the actual issue.
> 
> +1. makes sense to me.
> 
>> I like the vulnerabilities page we and Tomcat has very much as it eases 
>> the search and doesn't force me to got through changelogs
>> or other information not that quickly available.
> 
> Given the answer by Mark on extensibility of the cveprocess site, we 
> should make a solution based on our own pmc repository.
> 
> What makes most sense to me is to copy the CVE-JSON to the pmc repro, 
> when a CVE is "ready" (from our side) for a release. Let readiness.sh 
> check on that and also verify that all fields we need are in there.
> 
> Since we no longer need to have unreleased version numbers, we can make a 
> directory like "2.4.50" and add them there. The release scripts can then 
> pick them up, put the info in the CHANGES and add them to the site. With 
> an added "timeline" entry for date and release number.
 
 I understand that there is no need to burn version numbers any longer with 
 the new release scripts, but why would a failed release
 matter to this process?
>>> 
>>> 
>>> One thing that was nagging me in the release scripts: the steps run over 
>>> some time (up to a week possibly), and assume that nothing changes in the 
>>> pmc repository during this time. So the scripts might pick up a "ready" CVE 
>>> that is not part of the tarballs.
>>> 
>>> I was thinking of create a version directory to fix that, but that seems 
>>> overkill on reconsidering it. I am not thinking that the release
>> 
>> I am a little bit confused with this and the following sentence.
>> Do you want to say I am *not* thinking or I am thinking?
> 
> Sorry, not enough coffee. "I am *now* thinking..."

To spell it out more clearly:

- when a CVE is considered "ready" by us, but not set 
  to READY in the cveprocess (it is not released yet), 
  we manually copy the CVE-JSON from the site into 
  "pmc/SECURITY/" dir.
- cancelling a candidate would remove that dir again
- dev-tools/r4-stage-release.sh takes the CVEs from that
  dir and adds content to CHANGES, copies to site etc.

This means that when CVEs become ready after a candidate is
built, it won't slip accidentally into the announcements
or CHANGES.

There is the one manual step of copying, but the rest is
handled by scripts.

- Stefan

Re: [httpd-site] branch main updated: publishing release httpd-2.4.49

[ste...@eissing.org]

> Am 17.09.2021 um 11:18 schrieb Ruediger Pluem :
> 
> 
> 
> On 9/17/21 9:36 AM, ste...@eissing.org wrote:
>> 
>> 
>>> Am 17.09.2021 um 08:54 schrieb Ruediger Pluem :
>>> 
>>> 
>>> 
>>> On 9/16/21 10:12 PM, ste...@eissing.org wrote:
 
 
> Am 16.09.2021 um 21:44 schrieb Ruediger Pluem :
> 
> 
> 
> On 9/16/21 7:13 PM, Eric Covener wrote:
>> On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox  wrote:
>>> 
>>> Hi; at the moment the ASF customisation to the tool is tracked in my 
>>> github fork along with issues.  There's no specific place to discuss it 
>>> other than secur...@apache.org.  That's all just because there's only 
>>> me having worked on it.
>>> 
>>> There are going to be some big changes needed to the tool and running 
>>> instance in the coming months to support the new CVE Project v5.0 JSON 
>>> schema, as that is required for more of the future CVE project 
>>> automation (such as live submission to their database), so that will 
>>> likely take up all the time I can personally spend updating the tool in 
>>> the near future.
>> 
>> For the sake of discussion/argument: Do we want/need to reproduce this
>> information on the website or is linking to the changelog sufficient?
>> We lose our pseudo-scoring and the range of affected versions.  We
>> could bake them into our changelog-entry authoring/review.
> 
> I like to keep our current vulnerabilities page. On the contrary. I would 
> like to see it extended with the revision numbers that
> fixed the actual issue.
 
 +1. makes sense to me.
 
> I like the vulnerabilities page we and Tomcat has very much as it eases 
> the search and doesn't force me to got through changelogs
> or other information not that quickly available.
 
 Given the answer by Mark on extensibility of the cveprocess site, we 
 should make a solution based on our own pmc repository.
 
 What makes most sense to me is to copy the CVE-JSON to the pmc repro, when 
 a CVE is "ready" (from our side) for a release. Let readiness.sh check on 
 that and also verify that all fields we need are in there.
 
 Since we no longer need to have unreleased version numbers, we can make a 
 directory like "2.4.50" and add them there. The release scripts can then 
 pick them up, put the info in the CHANGES and add them to the site. With 
 an added "timeline" entry for date and release number.
>>> 
>>> I understand that there is no need to burn version numbers any longer with 
>>> the new release scripts, but why would a failed release
>>> matter to this process?
>> 
>> 
>> One thing that was nagging me in the release scripts: the steps run over 
>> some time (up to a week possibly), and assume that nothing changes in the 
>> pmc repository during this time. So the scripts might pick up a "ready" CVE 
>> that is not part of the tarballs.
>> 
>> I was thinking of create a version directory to fix that, but that seems 
>> overkill on reconsidering it. I am not thinking that the release
> 
> I am a little bit confused with this and the following sentence.
> Do you want to say I am *not* thinking or I am thinking?

Sorry, not enough coffee. "I am *now* thinking..."

> 
>> scripts should, when creating the candidate, create a pmc/SECURITY/version 
>> directory and move all ready CVEs there. Later stages of release scripts 
>> would them only consider those.
>> 
> 
> Regards
> 
> Rüdiger

Re: [httpd-site] branch main updated: publishing release httpd-2.4.49

[Ruediger Pluem]

On 9/17/21 9:36 AM, ste...@eissing.org wrote:
> 
> 
>> Am 17.09.2021 um 08:54 schrieb Ruediger Pluem :
>>
>>
>>
>> On 9/16/21 10:12 PM, ste...@eissing.org wrote:
>>>
>>>
 Am 16.09.2021 um 21:44 schrieb Ruediger Pluem :



 On 9/16/21 7:13 PM, Eric Covener wrote:
> On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox  wrote:
>>
>> Hi; at the moment the ASF customisation to the tool is tracked in my 
>> github fork along with issues.  There's no specific place to discuss it 
>> other than secur...@apache.org.  That's all just because there's only me 
>> having worked on it.
>>
>> There are going to be some big changes needed to the tool and running 
>> instance in the coming months to support the new CVE Project v5.0 JSON 
>> schema, as that is required for more of the future CVE project 
>> automation (such as live submission to their database), so that will 
>> likely take up all the time I can personally spend updating the tool in 
>> the near future.
>
> For the sake of discussion/argument: Do we want/need to reproduce this
> information on the website or is linking to the changelog sufficient?
> We lose our pseudo-scoring and the range of affected versions.  We
> could bake them into our changelog-entry authoring/review.

 I like to keep our current vulnerabilities page. On the contrary. I would 
 like to see it extended with the revision numbers that
 fixed the actual issue.
>>>
>>> +1. makes sense to me.
>>>
 I like the vulnerabilities page we and Tomcat has very much as it eases 
 the search and doesn't force me to got through changelogs
 or other information not that quickly available.
>>>
>>> Given the answer by Mark on extensibility of the cveprocess site, we should 
>>> make a solution based on our own pmc repository.
>>>
>>> What makes most sense to me is to copy the CVE-JSON to the pmc repro, when 
>>> a CVE is "ready" (from our side) for a release. Let readiness.sh check on 
>>> that and also verify that all fields we need are in there.
>>>
>>> Since we no longer need to have unreleased version numbers, we can make a 
>>> directory like "2.4.50" and add them there. The release scripts can then 
>>> pick them up, put the info in the CHANGES and add them to the site. With an 
>>> added "timeline" entry for date and release number.
>>
>> I understand that there is no need to burn version numbers any longer with 
>> the new release scripts, but why would a failed release
>> matter to this process?
> 
> 
> One thing that was nagging me in the release scripts: the steps run over some 
> time (up to a week possibly), and assume that nothing changes in the pmc 
> repository during this time. So the scripts might pick up a "ready" CVE that 
> is not part of the tarballs.
> 
> I was thinking of create a version directory to fix that, but that seems 
> overkill on reconsidering it. I am not thinking that the release

I am a little bit confused with this and the following sentence.
Do you want to say I am *not* thinking or I am thinking?

> scripts should, when creating the candidate, create a pmc/SECURITY/version 
> directory and move all ready CVEs there. Later stages of release scripts 
> would them only consider those.
> 

Regards

Rüdiger

Re: [httpd-site] branch main updated: publishing release httpd-2.4.49

[ste...@eissing.org]

> Am 17.09.2021 um 08:54 schrieb Ruediger Pluem :
> 
> 
> 
> On 9/16/21 10:12 PM, ste...@eissing.org wrote:
>> 
>> 
>>> Am 16.09.2021 um 21:44 schrieb Ruediger Pluem :
>>> 
>>> 
>>> 
>>> On 9/16/21 7:13 PM, Eric Covener wrote:
 On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox  wrote:
> 
> Hi; at the moment the ASF customisation to the tool is tracked in my 
> github fork along with issues.  There's no specific place to discuss it 
> other than secur...@apache.org.  That's all just because there's only me 
> having worked on it.
> 
> There are going to be some big changes needed to the tool and running 
> instance in the coming months to support the new CVE Project v5.0 JSON 
> schema, as that is required for more of the future CVE project automation 
> (such as live submission to their database), so that will likely take up 
> all the time I can personally spend updating the tool in the near future.
 
 For the sake of discussion/argument: Do we want/need to reproduce this
 information on the website or is linking to the changelog sufficient?
 We lose our pseudo-scoring and the range of affected versions.  We
 could bake them into our changelog-entry authoring/review.
>>> 
>>> I like to keep our current vulnerabilities page. On the contrary. I would 
>>> like to see it extended with the revision numbers that
>>> fixed the actual issue.
>> 
>> +1. makes sense to me.
>> 
>>> I like the vulnerabilities page we and Tomcat has very much as it eases the 
>>> search and doesn't force me to got through changelogs
>>> or other information not that quickly available.
>> 
>> Given the answer by Mark on extensibility of the cveprocess site, we should 
>> make a solution based on our own pmc repository.
>> 
>> What makes most sense to me is to copy the CVE-JSON to the pmc repro, when a 
>> CVE is "ready" (from our side) for a release. Let readiness.sh check on that 
>> and also verify that all fields we need are in there.
>> 
>> Since we no longer need to have unreleased version numbers, we can make a 
>> directory like "2.4.50" and add them there. The release scripts can then 
>> pick them up, put the info in the CHANGES and add them to the site. With an 
>> added "timeline" entry for date and release number.
> 
> I understand that there is no need to burn version numbers any longer with 
> the new release scripts, but why would a failed release
> matter to this process?


One thing that was nagging me in the release scripts: the steps run over some 
time (up to a week possibly), and assume that nothing changes in the pmc 
repository during this time. So the scripts might pick up a "ready" CVE that is 
not part of the tarballs.

I was thinking of create a version directory to fix that, but that seems 
overkill on reconsidering it. I am not thinking that the release
scripts should, when creating the candidate, create a pmc/SECURITY/version 
directory and move all ready CVEs there. Later stages of release scripts would 
them only consider those.

> 
>> 
>> The only manual thing is then to copy the JSON from the website once into a 
>> local file and the rest is automated. We can skip on creating a CHANGES per 
>> CVE and create that from the JSON. The CVEPROCESS file is then also 
>> obsolete. Just the existence of the JSON file in a version directory is 
>> enough.
> 
> Although I hate having a manual step in it, it sounds good. But I guess at 
> least short to mid term the manual step cannot be
> avoided. So lets go with it and make the best from the current. But if we no 
> longer create a CHANGES per CVE we need to fill out
> what should get into CHANGES somewhere in the CVE editor in an agreed field 
> and an agreed way (e.g. indenting). Furthermore the
> question is what happens to changes that become CVE's later and hence the 
> changes entry was already committed with the fix.

Hating manual too, but seems we cannot avoid that for some time.

We could also keep CHANGES, but I think we could also format the CVE-JSON in a 
much better way for the changelog entries, basically 
in a format similar to our vulnerabilities pages (which do take all data from 
CVE-JSON already).

Cheers,
Stefan

> 
> Regards
> 
> Rüdiger

Re: [httpd-site] branch main updated: publishing release httpd-2.4.49

[Ruediger Pluem]

On 9/16/21 10:12 PM, ste...@eissing.org wrote:
> 
> 
>> Am 16.09.2021 um 21:44 schrieb Ruediger Pluem :
>>
>>
>>
>> On 9/16/21 7:13 PM, Eric Covener wrote:
>>> On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox  wrote:

 Hi; at the moment the ASF customisation to the tool is tracked in my 
 github fork along with issues.  There's no specific place to discuss it 
 other than secur...@apache.org.  That's all just because there's only me 
 having worked on it.

 There are going to be some big changes needed to the tool and running 
 instance in the coming months to support the new CVE Project v5.0 JSON 
 schema, as that is required for more of the future CVE project automation 
 (such as live submission to their database), so that will likely take up 
 all the time I can personally spend updating the tool in the near future.
>>>
>>> For the sake of discussion/argument: Do we want/need to reproduce this
>>> information on the website or is linking to the changelog sufficient?
>>> We lose our pseudo-scoring and the range of affected versions.  We
>>> could bake them into our changelog-entry authoring/review.
>>
>> I like to keep our current vulnerabilities page. On the contrary. I would 
>> like to see it extended with the revision numbers that
>> fixed the actual issue.
> 
> +1. makes sense to me.
> 
>> I like the vulnerabilities page we and Tomcat has very much as it eases the 
>> search and doesn't force me to got through changelogs
>> or other information not that quickly available.
> 
> Given the answer by Mark on extensibility of the cveprocess site, we should 
> make a solution based on our own pmc repository.
> 
> What makes most sense to me is to copy the CVE-JSON to the pmc repro, when a 
> CVE is "ready" (from our side) for a release. Let readiness.sh check on that 
> and also verify that all fields we need are in there.
> 
> Since we no longer need to have unreleased version numbers, we can make a 
> directory like "2.4.50" and add them there. The release scripts can then pick 
> them up, put the info in the CHANGES and add them to the site. With an added 
> "timeline" entry for date and release number.

I understand that there is no need to burn version numbers any longer with the 
new release scripts, but why would a failed release
matter to this process?

> 
> The only manual thing is then to copy the JSON from the website once into a 
> local file and the rest is automated. We can skip on creating a CHANGES per 
> CVE and create that from the JSON. The CVEPROCESS file is then also obsolete. 
> Just the existence of the JSON file in a version directory is enough.

Although I hate having a manual step in it, it sounds good. But I guess at 
least short to mid term the manual step cannot be
avoided. So lets go with it and make the best from the current. But if we no 
longer create a CHANGES per CVE we need to fill out
what should get into CHANGES somewhere in the CVE editor in an agreed field and 
an agreed way (e.g. indenting). Furthermore the
question is what happens to changes that become CVE's later and hence the 
changes entry was already committed with the fix.

Regards

Rüdiger