Closed reneeb closed 1 year ago
I say update the ID in the YAML file.
I'd probably use make_record to create the new string and then update the file by hand. I wouldn't do anything to try to replace existing records since there can be other edits that we want to preserve. Programming something to figure all that out will likely take more time than just hand edits.
Automation is as big a win here as one might think. Looking at the new references for Gitlab::API::v4, I see most of them are junk thread messages. I tend to read all the links to see which are relevant anyway.
I've fixed both of the particular issues.
The CPANSA id might be used as a reference by someone else. I'd keep the YAML for the old ID but remove most of the information leave a description to say it's been reassigned to a new number.
I thought about how that would affect someone tracking an ID, such as a list of things they want to ignore. That problem is that creating a new record still won't be ignored and they'll have to add it to their list anyway. The least complicated thing to do is just update the ID and leave it at that. Otherwise, we have a new record type that all the tools have to understand, which will be a lot more confusion. Since this will rarely happen, the win in simplicity.
But, I did go back to add a previous_id
field to the record.
An issue in CPAN.pm was added with commit d6b37158588993a4183b3852cfbd973805d2e438 . The issue now has an CVE entry: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-31484
Should we change the id in the yaml file?
Should we update issues when Mitre added some references? E.g. the Gitlab::API::v4 entry (CVE-2023-31485) was updated since it was added to this repository. Should we update make_record to recognise entries for a CVE and update the YAML file?