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?
>
> 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.
Although I hate having a manual step in it, it sounds good. But I guess at
least short to mid term the manual step cannot be
avoided. So lets go with it and make the best from the current. But if we no
longer create a CHANGES per CVE we need to fill out
what should get into CHANGES somewhere in the CVE editor in an agreed field and
an agreed way (e.g. indenting). Furthermore the
question is what happens to changes that become CVE's later and hence the
changes entry was already committed with the fix.
Regards
Rüdiger
