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?
> 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
