npm vulnerabilities seem flagged as ecosystem yet looking at detail of ranges appear to be semver about advisory-database HOT 5 CLOSED

thanks for the links Chris had missed that softened position so get it now so closing this.

from advisory-database.

Hi @MikeMoore63. I'm not sure what you mean by it changing from SEMVER to ECOSYSTEM, as we have always output the types as ECOSYSTEM since our early prototypes of the transformation process. That said, I understand why you might have questions about using ECOSYSTEM over SEMVER. The short answer is because we don't currently have any ecosystem-specific transformation process in place (it's all done through a single common transformation process), though that is something that we have on our backlog. The reason why this leads to using ECOSYSTEM over SEMVER is that not all of the ecosystems we currently support in our curation process enforce strict SemVer 2.0 versioning, so we mark them all as ECOSYSTEM to let receiving systems know that they should use the ecosystem's package manager to determine what's affected rather than rely on SemVer semantics.

from advisory-database.

Hey Chris

So I am just reading the spec and if you don't know what you support I would think the ecosystem field should be null rather than ECOSYSTEM. I am taking th efeed one down from the google osvvulnerabilities and that is likely what changed but i think its based on adoption within here of the osv spec.

Its really confusing as it stands as you specify semver rangess but say its not SEMVER and its ECOSYSTEM in which case the spec states provide versions not ranges. so while I appreciate you ar elikely correct that you have produced ECOSYSTEM as a consumer of data its not making a lot of sense based onwhat the spec states.

So just saying that some work is likely required maybe even on the spec to handle this case where the source doesn't know.

Thanks

Mike

from advisory-database.

The issue with using SEMVER is a little pedantic - many ecosystems say they follow SemVer versioning but they don't really enforce it and so package maintainers publish version strings that are SemVer-like but do not really follow the spec. So even if we specified the type as SEMVER, unless you know for sure that the package ecosystem enforces this, you could run into problems parsing the version ranges using just SemVer semantics. By specifying the ECOSYSTEM type, we're saying you should always use the package manager of the ecosystem to resolve these ranges to lists of affected versions, since even if the maintainers didn't follow strict SemVer 2.0, they would have, presumably, followed the format their package manager expects in order to have their versions appear in the correct linear order.

According to the OSV spec (v1.2):

Some ecosystems may recommend using SemVer 2.0 for versioning without explicitly enforcing it. In those cases you should use the ECOSYSTEM type instead.

This is the approach we've taken, though as I mentioned previously we're working on switching to SEMVER for those ecosystems that do in fact enforce strict SemVer version names.

Its really confusing as it stands as you specify semver rangess but say its not SEMVER and its ECOSYSTEM in which case the spec states provide versions not ranges.

While earlier versions of the spec required an explicit list of versions when using the ECOSYSTEM type, that requirement has since been softened. Specifying ranges has always been acceptable with that range type.

from advisory-database.

to be clear, npm basically follows semver 1.0. It's worth noting that a) ranges aren't part of the semver spec whatsoever, although npm's range specification may soon become so (semver/semver#584), and b) for versions under 1.0, npm's rules are that in v0.X.Y and x0.0.X, X is the major, and Y is minor/patch, whereas semver 2 says "everything under 1.0 is always a breaking change".

from advisory-database.