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