> 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
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.
>
>>
>> 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.
Hating manual too, but seems we cannot avoid that for some time.
We could also keep CHANGES, but I think we could also format the CVE-JSON in a
much better way for the changelog entries, basically
in a format similar to our vulnerabilities pages (which do take all data from
CVE-JSON already).
Cheers,
Stefan
>
> Regards
>
> Rüdiger
