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