-
Notifications
You must be signed in to change notification settings - Fork 85
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
Pull SEMVER range for npm vuln #1206
Comments
@hdonnay @crozzy - I am looking into providing a PR for it - |
No; if you want to look at OSV, that's over in the osv package. |
@hdonnay looking at the code - I am not sure why it does not take the Introduced from the second range...
should give me only the fixed in version, as the introduced is 0
should have created an introduced unless we believe the issue is here
and this throws an error ? |
I tested and the NewVersion works
and thus I need to update the fixedin version to have something like
? |
Yes, if the version contains non-numeric components it can't get normalized into claircore's range type. It should still be encoded in the "FixedInVersion". |
@hdonnay thanks - trying to figure out why
gets us fixed=2.6.10&introduced=2.0.0-beta.4 |
I'm not sure what you're saying, here. I would expect the information persisted into the database to not have a |
Got it - analysis
https://api.osv.dev/v1/vulns/GHSA-q4q5-c5cv-2p68
|
SELECT name,package_name,repo_name,fixed_in_version,vulnerable_range,version_kind FROM public.vuln
https://api.osv.dev/v1/vulns/GHSA-67hx-6x53-jw92
Let me see what is different |
interesting - maybe the issue is is that the introduced == fixedin in case I remove -alpha - I need to check |
ah, you're comparing across an |
Ok so what should this one become ?
should it be
or
I believe the first one right ? because the introduced AND fixed in version do contain invalid SEMVER - should we move it to this code ?
even though it is a SEMVER and the ecosystem is npm ? Notice that this one
became this
so it dropped the beta.4 from 2.0.0 |
we might hit this if both upper and lower are the same in this unique case
|
I am going to implement as follow
|
something like
and
@hdonnay ? |
Investigate why the old entry is still there - the MD5 calculation may have failed |
@hdonnay is there a way I can force the osv/updater to update all record regardless if the hash is the same or not ? |
returns no range but the osv data has some - https://api.osv.dev/v1/vulns/GHSA-67hx-6x53-jw92
and
The text was updated successfully, but these errors were encountered: