feat: Implement Hex Enumerable Ecosystem

[maennchen]

Should provide detailed version list for data sources like GHSA.

Example: https://osv.dev/vulnerability/GHSA-9fm9-hp7p-53mf

Uses the /packages/{package} HEX API. Spec: https://github.com/hexpm/specifications/blob/72dc140b8766f687869d3265c88a6725021cdbc1/apiary.apib#L428

[another-rex]

Thanks for the PR! Can I ask whether there's a specific use case for enumerating versions? We generally don't enumerate versions for ecosystems with SEMVER type versions, as they are easily comparable.

We are happy to look into supporting enumerating versions for SEMVER types if there's a good use case, though it would require a bit of work.

[maennchen]

@another-rex The primary intent behind this change was to bring feature parity to non-EEF source reports. EEF provides a list of versions with the OSV data, but others like GHSA do not.

Additionally, having the versions pre-resolved makes the implementation with some tooling that we're planning simpler. Essentially I can join OSV information taken from an OSV dump, upsert it into a DB table and I have all the information for a join to a release. If we need to evaluate the events, that is some extra work that we need to do outside the DB / at runtime. This use case can however be implemented as well with some extra work if OSV does not wish to include this change.

Is there any downsides to adding this?

[michaelkedar]

Really sorry for the delay on reviewing this!

I think this should be fine to add to OSV. I had a quick look into the code and it seems like version enumeration would indeed happen on SEMVER ecosystems that support it.

One limitation to note is that OSV does not automatically re-enumerate versions of older records. This would usually only a problem if there's an unfixed vulnerability in a package which is continuing to release new versions. (Though, since all current Hex vulnerabilities have a fixed version, this might be a non-issue).

When we get this released, I can trigger a re-import of all the Hex records to get the versions enumerated.

[maennchen]

This would usually only a problem if there's an unfixed vulnerability in a package which is continuing to release new versions.

I'll make sure to add a check once we implement #1276 to trigger a follow up if the new published version matches an existing vulnerability affected range. In this case we most likely will have to adjust the underlying advisory anyways.

[michaelkedar]

/gcbrun

[maennchen]

@michaelkedar Sorry, there was a formatting issue. I've reformatted

[another-rex]

/gcbrun

[maennchen]

@another-rex Something is up with the formatter. I ran yapf locally. Pushing again.

[another-rex]

/gcbrun

[maennchen]

@michaelkedar Updated. Sorry about the mess in this PR.

[another-rex]

/gcbrun