> 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..."
>
>> 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
