briandfoy
commented
3 months ago I don't mind adding other fields, and a purl field will be fine. However, after reading the purl stuff it seems it doesn't quite fit.
- The namespace of a particular Perl distribution is not fixed, so there are a lot of questions about what to put there. Even if we add an author, we do not know that at some future time it is still correct. It can be empty though.
- The version is problematic since each report here is a collection of reports across the entire lifetime of the package. But the version doesn't have to appear.
- If both namespace and version are blank, there is nothing to do since the purl is a composite field. You know it's CPAN (mostly) and you know the distribution name. An additional field the combines those two in a string adds no value. Something else can use the existing reports to do other things.
- Since all the necessary information is already in the report, I don't see what's necessary about this change. Anything that wants to generate this information can already do that.
- CPAN isn't the only source of Perl modules. We'd have to include the various vendor packages too. That would be an interesting addition to this data.
- I don't see how Google would use the reports in this project directly. We'd have to convert them to their OSV format. As such, there's no need to add additional information in the reports. Instead, we'd repackage what we already have into new output formats.
- I'm already including the GitHub ID for these issues, but that's not something I could generate from the existing data.
- Most of the data Google wants is already classified in the CVEs.
But, I'm also wary of any Google project, especially when we already have ways to get this information for other sources that are already doing this work. In two years when Google gets tired of this, we're back to what we've been using for decades.
I think the path forward is a program that converts the data here into the format that Google needs. That doesn't require a change to the CPANSA.pm module.
And, let's use URI::PackageURL.
See the PURL spec and the CPAN-specific PURL spec:
The algorithm for generation matches that used in URI::PackageURL.
This change is necessary but not necessarily sufficient to use this security database as a source to the Open Source Vulnerabilities aggregator, as described in the OSV announcement.
I've marked this as a draft because I'm interested to discuss the goal I've laid out here, and am happy to revise the implementation, if desired.