Mailing List Archive

> Am 16.09.2021 um 14:04 schrieb Ruediger Pluem <rpluem@apache.org>:
>
>
>
> On 9/16/21 12:33 PM, icing@apache.org wrote:
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> icing pushed a commit to branch main
>> in repository https://gitbox.apache.org/repos/asf/httpd-site.git
>>
>>
>> The following commit(s) were added to refs/heads/main by this push:
>> new 51476c4 publishing release httpd-2.4.49
>> 51476c4 is described below
>>
>> commit 51476c4d2261ea5b68951054a50c08a249ea1306
>> Author: Stefan Eissing <stefan.eissing@greenbytes.de>
>> AuthorDate: Thu Sep 16 09:58:23 2021 +0200
>>
>> publishing release httpd-2.4.49
>> ---
>> content/doap.rdf | 4 ++--
>> content/download.md | 24 ++++++++++++------------
>> content/index.md | 6 +++---
>> 3 files changed, 17 insertions(+), 17 deletions(-)
>
> The vulnerabilties page is not updated yet. I guess this can be fixed by copying the respective json files
> to https://github.com/apache/httpd-site/tree/main/content/security/json
> Does https://cveprocess.apache.org/ provide any RESTFUL API to extract the JSON from the tool such that this can be scripted?

With links such as these it looks unguessable

blob:https://cveprocess.apache.org/3c51c80b-1d31-403a-9d1d-95c928f91574

(involuntarily learning about 'blob:' url schemes...aaahhhhh!)

>
> Regards
>
> Rüdiger
>
>

> Am 16.09.2021 um 14:14 schrieb stefan@eissing.org:
>
>>
>> Am 16.09.2021 um 14:04 schrieb Ruediger Pluem <rpluem@apache.org>:
>>
>>
>>
>> On 9/16/21 12:33 PM, icing@apache.org wrote:
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> icing pushed a commit to branch main
>>> in repository https://gitbox.apache.org/repos/asf/httpd-site.git
>>>
>>>
>>> The following commit(s) were added to refs/heads/main by this push:
>>> new 51476c4 publishing release httpd-2.4.49
>>> 51476c4 is described below
>>>
>>> commit 51476c4d2261ea5b68951054a50c08a249ea1306
>>> Author: Stefan Eissing <stefan.eissing@greenbytes.de>
>>> AuthorDate: Thu Sep 16 09:58:23 2021 +0200
>>>
>>> publishing release httpd-2.4.49
>>> ---
>>> content/doap.rdf | 4 ++--
>>> content/download.md | 24 ++++++++++++------------
>>> content/index.md | 6 +++---
>>> 3 files changed, 17 insertions(+), 17 deletions(-)
>>
>> The vulnerabilties page is not updated yet. I guess this can be fixed by copying the respective json files
>> to https://github.com/apache/httpd-site/tree/main/content/security/json
>> Does https://cveprocess.apache.org/ provide any RESTFUL API to extract the JSON from the tool such that this can be scripted?
>
> With links such as these it looks unguessable
>
> blob:https://cveprocess.apache.org/3c51c80b-1d31-403a-9d1d-95c928f91574
>
> (involuntarily learning about 'blob:' url schemes...aaahhhhh!)

And analyzing the page, the JSON data is embedded in the Javascript embedded in the HTML. Hmm...

>
>>
>> Regards
>>
>> Rüdiger

Rüdiger, you are also probably looking at this. Who runs he shell scripts to generate the mds? It seems we need to do that on changing the cves?

Also, the converter script stumbles on CVEs without "timeline".

Are you on it or should I?

> Am 16.09.2021 um 14:17 schrieb stefan@eissing.org:
>
>
>
>> Am 16.09.2021 um 14:14 schrieb stefan@eissing.org:
>>
>>>
>>> Am 16.09.2021 um 14:04 schrieb Ruediger Pluem <rpluem@apache.org>:
>>>
>>>
>>>
>>> On 9/16/21 12:33 PM, icing@apache.org wrote:
>>>> This is an automated email from the ASF dual-hosted git repository.
>>>>
>>>> icing pushed a commit to branch main
>>>> in repository https://gitbox.apache.org/repos/asf/httpd-site.git
>>>>
>>>>
>>>> The following commit(s) were added to refs/heads/main by this push:
>>>> new 51476c4 publishing release httpd-2.4.49
>>>> 51476c4 is described below
>>>>
>>>> commit 51476c4d2261ea5b68951054a50c08a249ea1306
>>>> Author: Stefan Eissing <stefan.eissing@greenbytes.de>
>>>> AuthorDate: Thu Sep 16 09:58:23 2021 +0200
>>>>
>>>> publishing release httpd-2.4.49
>>>> ---
>>>> content/doap.rdf | 4 ++--
>>>> content/download.md | 24 ++++++++++++------------
>>>> content/index.md | 6 +++---
>>>> 3 files changed, 17 insertions(+), 17 deletions(-)
>>>
>>> The vulnerabilties page is not updated yet. I guess this can be fixed by copying the respective json files
>>> to https://github.com/apache/httpd-site/tree/main/content/security/json
>>> Does https://cveprocess.apache.org/ provide any RESTFUL API to extract the JSON from the tool such that this can be scripted?
>>
>> With links such as these it looks unguessable
>>
>> blob:https://cveprocess.apache.org/3c51c80b-1d31-403a-9d1d-95c928f91574
>>
>> (involuntarily learning about 'blob:' url schemes...aaahhhhh!)
>
> And analyzing the page, the JSON data is embedded in the Javascript embedded in the HTML. Hmm...
>
>>
>>>
>>> Regards
>>>
>>> Rüdiger

On 9/16/21 2:14 PM, stefan@eissing.org wrote:
>
>> Am 16.09.2021 um 14:04 schrieb Ruediger Pluem <rpluem@apache.org>:
>>
>>
>>
>> On 9/16/21 12:33 PM, icing@apache.org wrote:
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> icing pushed a commit to branch main
>>> in repository https://gitbox.apache.org/repos/asf/httpd-site.git
>>>
>>>
>>> The following commit(s) were added to refs/heads/main by this push:
>>> new 51476c4 publishing release httpd-2.4.49
>>> 51476c4 is described below
>>>
>>> commit 51476c4d2261ea5b68951054a50c08a249ea1306
>>> Author: Stefan Eissing <stefan.eissing@greenbytes.de>
>>> AuthorDate: Thu Sep 16 09:58:23 2021 +0200
>>>
>>> publishing release httpd-2.4.49
>>> ---
>>> content/doap.rdf | 4 ++--
>>> content/download.md | 24 ++++++++++++------------
>>> content/index.md | 6 +++---
>>> 3 files changed, 17 insertions(+), 17 deletions(-)
>>
>> The vulnerabilties page is not updated yet. I guess this can be fixed by copying the respective json files
>> to https://github.com/apache/httpd-site/tree/main/content/security/json

I just downloaded the files manually and commited them in 645a263259cad97a39f1ba0e0689ec2476d429da. But this breaks the site.
Hence I reverted. Looks like that the downloaded json misses data.

>> Does https://cveprocess.apache.org/ provide any RESTFUL API to extract the JSON from the tool such that this can be scripted?
>
> With links such as these it looks unguessable
>
> blob:https://cveprocess.apache.org/3c51c80b-1d31-403a-9d1d-95c928f91574
>
> (involuntarily learning about 'blob:' url schemes...aaahhhhh!)
>
>>

Regards

Rüdiger

On 9/16/21 2:25 PM, stefan@eissing.org wrote:
> Rüdiger, you are also probably looking at this. Who runs he shell scripts to generate the mds? It seems we need to do that on changing the cves?

These are run on github side when you commit.

>
> Also, the converter script stumbles on CVEs without "timeline".

Yes, CVE-2021-34798 CVE-2021-39275 CVE-2021-40438 are missing the timeline

Regards

Rüdiger

>
> Are you on it or should I?

Are you able to update the timeline in 3 ones above?

Regards

Rüdiger

Just pushed and it updated.

Summary:
- the "optional" timeline needs to contain an entry "2.4.49 released" or the conversion fails
- the "version_affected" combobox field in the UI needs a selection other than default or the conversion fails

Something to improve in the cveprocess and our release scripts.

> Am 16.09.2021 um 14:38 schrieb Ruediger Pluem <rpluem@apache.org>:
>
>
>
> On 9/16/21 2:25 PM, stefan@eissing.org wrote:
>> Rüdiger, you are also probably looking at this. Who runs he shell scripts to generate the mds? It seems we need to do that on changing the cves?
>
> These are run on github side when you commit.
>
>>
>> Also, the converter script stumbles on CVEs without "timeline".
>
> Yes, CVE-2021-34798 CVE-2021-39275 CVE-2021-40438 are missing the timeline
>
> Regards
>
> Rüdiger
>
>>
>> Are you on it or should I?
>
> Are you able to update the timeline in 3 ones above?
>
> Regards
>
> Rüdiger
>

And thanks, Rüdiger, for noticing and the quick fixes.\o/

> Am 16.09.2021 um 14:53 schrieb stefan@eissing.org:
>
> Just pushed and it updated.
>
> Summary:
> - the "optional" timeline needs to contain an entry "2.4.49 released" or the conversion fails
> - the "version_affected" combobox field in the UI needs a selection other than default or the conversion fails
>
> Something to improve in the cveprocess and our release scripts.
>
>> Am 16.09.2021 um 14:38 schrieb Ruediger Pluem <rpluem@apache.org>:
>>
>>
>>
>> On 9/16/21 2:25 PM, stefan@eissing.org wrote:
>>> Rüdiger, you are also probably looking at this. Who runs he shell scripts to generate the mds? It seems we need to do that on changing the cves?
>>
>> These are run on github side when you commit.
>>
>>>
>>> Also, the converter script stumbles on CVEs without "timeline".
>>
>> Yes, CVE-2021-34798 CVE-2021-39275 CVE-2021-40438 are missing the timeline
>>
>> Regards
>>
>> Rüdiger
>>
>>>
>>> Are you on it or should I?
>>
>> Are you able to update the timeline in 3 ones above?
>>
>> Regards
>>
>> Rüdiger
>>
>

On 9/16/21 2:59 PM, stefan@eissing.org wrote:
> And thanks, Rüdiger, for noticing and the quick fixes.\o/

And thanks to you for all the release and scripting work.

Regards

Rüdiger

> Am 16.09.2021 um 15:01 schrieb Ruediger Pluem <rpluem@apache.org>:
>
>
>
> On 9/16/21 2:59 PM, stefan@eissing.org wrote:
>> And thanks, Rüdiger, for noticing and the quick fixes.\o/
>
> And thanks to you for all the release and scripting work.

I think we should request some download url feature from the cveprocess, so that we can automate that part as well. The timeline entry should be added automatically. The "affected_by" we can at least check and report.


>
> Regards
>
> Rüdiger
>

On Thu, Sep 16, 2021 at 9:07 AM stefan@eissing.org <stefan@eissing.org> wrote:
>
>
>
> > Am 16.09.2021 um 15:01 schrieb Ruediger Pluem <rpluem@apache.org>:
> >
> >
> >
> > On 9/16/21 2:59 PM, stefan@eissing.org wrote:
> >> And thanks, Rüdiger, for noticing and the quick fixes.\o/
> >
> > And thanks to you for all the release and scripting work.
>
> I think we should request some download url feature from the cveprocess, so that we can automate that part as well. The timeline entry should be added automatically. The "affected_by" we can at least check and report.

I'm not sure we have Mark watching here, best to take it to the two
security lists.

On 9/16/21 3:16 PM, Eric Covener wrote:
> On Thu, Sep 16, 2021 at 9:07 AM stefan@eissing.org <stefan@eissing.org> wrote:
>>
>>
>>
>>> Am 16.09.2021 um 15:01 schrieb Ruediger Pluem <rpluem@apache.org>:
>>>
>>>
>>>
>>> On 9/16/21 2:59 PM, stefan@eissing.org wrote:
>>>> And thanks, Rüdiger, for noticing and the quick fixes.\o/
>>>
>>> And thanks to you for all the release and scripting work.
>>
>> I think we should request some download url feature from the cveprocess, so that we can automate that part as well. The timeline entry should be added automatically. The "affected_by" we can at least check and report.
>
> I'm not sure we have Mark watching here, best to take it to the two

I fear that as well, but I wanted to avoid crosposts on dev@ and security@ at the same time due to their different visibility.
In general I think improvements to the CVE tool can be discussed in public, but I am not sure what the correct venue aka list is
for this topic.
@Mark: Can you give us a hint what is the correct forum to talk about improvements of the CVE tool?

> security lists.
>

Regards

Rüdiger

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
security@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.

Issues:
https://github.com/iamamoose/Vulnogram/issues

ASF changes from the upstream Vulnogram code:
https://github.com/Vulnogram/Vulnogram/compare/master...iamamoose:asfmaster

Regards, Mark J Cox
ASF Security


On Thu, Sep 16, 2021 at 4:57 PM Ruediger Pluem <rpluem@apache.org> wrote:

>
>
> On 9/16/21 3:16 PM, Eric Covener wrote:
> > On Thu, Sep 16, 2021 at 9:07 AM stefan@eissing.org <stefan@eissing.org>
> wrote:
> >>
> >>
> >>
> >>> Am 16.09.2021 um 15:01 schrieb Ruediger Pluem <rpluem@apache.org>:
> >>>
> >>>
> >>>
> >>> On 9/16/21 2:59 PM, stefan@eissing.org wrote:
> >>>> And thanks, Rüdiger, for noticing and the quick fixes.\o/
> >>>
> >>> And thanks to you for all the release and scripting work.
> >>
> >> I think we should request some download url feature from the
> cveprocess, so that we can automate that part as well. The timeline entry
> should be added automatically. The "affected_by" we can at least check and
> report.
> >
> > I'm not sure we have Mark watching here, best to take it to the two
>
> I fear that as well, but I wanted to avoid crosposts on dev@ and security@
> at the same time due to their different visibility.
> In general I think improvements to the CVE tool can be discussed in
> public, but I am not sure what the correct venue aka list is
> for this topic.
> @Mark: Can you give us a hint what is the correct forum to talk about
> improvements of the CVE tool?
>
> > security lists.
> >
>
> Regards
>
> Rüdiger
>

On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox <mjc@apache.org> 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 security@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.

On 9/16/21 7:13 PM, Eric Covener wrote:
> On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox <mjc@apache.org> 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 security@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.
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.

Regards

Rüdiger

> Am 16.09.2021 um 21:44 schrieb Ruediger Pluem <rpluem@apache.org>:
>
>
>
> On 9/16/21 7:13 PM, Eric Covener wrote:
>> On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox <mjc@apache.org> 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 security@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.

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.

- Stefan

On 9/16/21 10:12 PM, stefan@eissing.org wrote:
>
>
>> Am 16.09.2021 um 21:44 schrieb Ruediger Pluem <rpluem@apache.org>:
>>
>>
>>
>> On 9/16/21 7:13 PM, Eric Covener wrote:
>>> On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox <mjc@apache.org> 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 security@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

> Am 17.09.2021 um 08:54 schrieb Ruediger Pluem <rpluem@apache.org>:
>
>
>
> On 9/16/21 10:12 PM, stefan@eissing.org wrote:
>>
>>
>>> Am 16.09.2021 um 21:44 schrieb Ruediger Pluem <rpluem@apache.org>:
>>>
>>>
>>>
>>> On 9/16/21 7:13 PM, Eric Covener wrote:
>>>> On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox <mjc@apache.org> 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 security@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

On 9/17/21 9:36 AM, stefan@eissing.org wrote:
>
>
>> Am 17.09.2021 um 08:54 schrieb Ruediger Pluem <rpluem@apache.org>:
>>
>>
>>
>> On 9/16/21 10:12 PM, stefan@eissing.org wrote:
>>>
>>>
>>>> Am 16.09.2021 um 21:44 schrieb Ruediger Pluem <rpluem@apache.org>:
>>>>
>>>>
>>>>
>>>> On 9/16/21 7:13 PM, Eric Covener wrote:
>>>>> On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox <mjc@apache.org> 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 security@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

> Am 17.09.2021 um 11:18 schrieb Ruediger Pluem <rpluem@apache.org>:
>
>
>
> On 9/17/21 9:36 AM, stefan@eissing.org wrote:
>>
>>
>>> Am 17.09.2021 um 08:54 schrieb Ruediger Pluem <rpluem@apache.org>:
>>>
>>>
>>>
>>> On 9/16/21 10:12 PM, stefan@eissing.org wrote:
>>>>
>>>>
>>>>> Am 16.09.2021 um 21:44 schrieb Ruediger Pluem <rpluem@apache.org>:
>>>>>
>>>>>
>>>>>
>>>>> On 9/16/21 7:13 PM, Eric Covener wrote:
>>>>>> On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox <mjc@apache.org> 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 security@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

> Am 17.09.2021 um 11:20 schrieb stefan@eissing.org:
>
>
>
>> Am 17.09.2021 um 11:18 schrieb Ruediger Pluem <rpluem@apache.org>:
>>
>>
>>
>> On 9/17/21 9:36 AM, stefan@eissing.org wrote:
>>>
>>>
>>>> Am 17.09.2021 um 08:54 schrieb Ruediger Pluem <rpluem@apache.org>:
>>>>
>>>>
>>>>
>>>> On 9/16/21 10:12 PM, stefan@eissing.org wrote:
>>>>>
>>>>>
>>>>>> Am 16.09.2021 um 21:44 schrieb Ruediger Pluem <rpluem@apache.org>:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 9/16/21 7:13 PM, Eric Covener wrote:
>>>>>>> On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox <mjc@apache.org> 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 security@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/<cve_dir/CVE.json.
- tools/readiness.sh checks that file for completeness
- dev-tools/release/r0-make-candidate.sh copies those
files into "pmc/SECURITY/release-<version>" 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

On 9/17/21 11:29 AM, stefan@eissing.org wrote:
>
>
>> Am 17.09.2021 um 11:20 schrieb stefan@eissing.org:
>>
>>
>>
>>> Am 17.09.2021 um 11:18 schrieb Ruediger Pluem <rpluem@apache.org>:
>>>
>>>
>>>
>>> On 9/17/21 9:36 AM, stefan@eissing.org wrote:
>>>>
>>>>
>>>>> Am 17.09.2021 um 08:54 schrieb Ruediger Pluem <rpluem@apache.org>:
>>>>>
>>>>>
>>>>>
>>>>> On 9/16/21 10:12 PM, stefan@eissing.org wrote:
>>>>>>
>>>>>>
>>>>>>> Am 16.09.2021 um 21:44 schrieb Ruediger Pluem <rpluem@apache.org>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 9/16/21 7:13 PM, Eric Covener wrote:
>>>>>>>> On Thu, Sep 16, 2021 at 12:58 PM Mark J Cox <mjc@apache.org> 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 security@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/<cve_dir/CVE.json.
> - tools/readiness.sh checks that file for completeness
> - dev-tools/release/r0-make-candidate.sh copies those
> files into "pmc/SECURITY/release-<version>" 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