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 <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.
Thanks for the clarification. +1 to the steps above.
Regards
Rüdiger
