-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
npm vulnerabilities seem flagged as ecosystem yet looking at detail of ranges appear to be semver #36
Comments
Hi @MikeMoore63. I'm not sure what you mean by it changing from SEMVER to ECOSYSTEM, as we have always output the types as |
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 |
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):
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.
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. |
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 |
thanks for the links Chris had missed that softened position so get it now so closing this. |
I have noticed recently the npm vulnerability affected ranges types changed from SEMVER to ECOSYSTEM but the way the impacted versions are described are described as if SEMVER using the introduced and fixed and no versions list is defined which is what the spec suggest should be done.
i am looking at the spec here https://ossf.github.io/osv-schema/#affectedrangestype-field
Any reason why this has changed as it did used to be correct ?
An example is GHSA-mf22-92pm-m8p8
The text was updated successfully, but these errors were encountered: