Non-SemVer compliant versioning in OSV records #336
Comments
|
Hi @andrewpollock, Thanks for letting us know and for opening this issue. We are working on a fix. |
|
Hi @andrewpollock, Just a quick note to let you know we have updated our database fixing this issue. We are now distributing the affected ranges in Let us know if there is anything else we can help you with. |
|
Thanks for the quick action. Unfortunately I failed to appreciate that OSV.dev is expecting this ecosystem to be SemVer I've cross referenced the contents of the source repo with what's missing from OSV.dev's export (so is therefore failing import), and these records are problematic as SemVer: |
|
Hi @andrewpollock, Thanks for your message. Unfortunately, we distribute third-party projects for which we don't have any control on their versioning system. Most of the times, and for most of the projects we distribute, upstream releases are named with valid SemVer schema, but from time to time they may release a version without honoring it. Is it possible to update osv.dev backend to accept a mix of |
|
Hi @gongomgra, (/cc @oliverchang to keep me honest here) I've got a better appreciation for what's happening here now, see below for what I think needs to happen. If you would like to have a meeting to talk through this, please let me know. See https://google.github.io/osv.dev/faq/#what-does-osvdev-do-to-the-records-it-imports for additional background context. When an OSV ecosystem (really an OSV.dev "source" in this context) is treated as
For Given Bitnami's need for a mixed ecosystem (really an OSV.dev "source" in this context), I think the path forwards, to ensure the records mentioned in #336 (comment) can be successfully imported (and are usable), what is going to be needed is custom enumeration code for the Bitnami ecosystem that:
Note that this is going to mean that for every new non-SemVer package that is added to Bitnami/has an OSV vulnerability record published, this custom version enumeration code is going to need to be extended in order for OSV records for that package to be successfully imported by OSV.dev The above failures cluster by package: |
|
Is there documentation for how Bitnami treats version numbers and the algorithms/rules i follows? For instance, how does Bitnami determine if a particular version number is newer than another for the purposes of upgrading packages? Ideally osv.dev behaviour will match this exactly. As @andrewpollock mentioned, our |
|
Hi @andrewpollock, @oliverchang, Sorry for the delay. Almost all of our assets follow the semver specs to name their released versions. If one asset publishes a release with a non-semver tag (let's take a recent case I have found for rails: Having the mentioned logic into account, would that work if we continue adding the non-semver versions into the |
|
Hi @gongomgra As I mentioned previously in #336 (comment), if OSV.dev is to do anything outside of treating everything from Bitnami as It seems feasible to me to have this code behave as I described in my earlier comment.
No, this is the first time we've had this sort of scenario, where an OSV.dev database is mixing version range types.
Just be aware that for an ECOSYSTEM range with incomplete enumeration (i.e. |
|
Hi @andrewpollock, @oliverchang, We are working on fixing the affected CVE files mentioned here and also others we have found on our side. We will keep you posted. |
|
Hi @andrewpollock, @oliverchang, We have fixed and/or removed (turned out some of them didn't affect our released assets) all affected CVEs in our database (see PR/369). Please let us know if the osv.dev ingestion is ok now. |
|
Hi @andrewpollock, @oliverchang, Do you have any update on this? |
|
Hi @gongomgra I have cross-referenced the Git repository we're importing from with the contents of what we're exporting: but, I see: It looks like a number of previously published advisories have been subsequently deleted? a) Is it conceivable that a Bitnami customer would have old (vulnerable) packages installed and be getting false negatives if this data was no longer present in OSV,.dev? These are what I'm seeing present in the export, but no longer in the source repo we're importing from: |
|
I think this is all good now in terms of what's currently existent importing correctly, there's just the open question around whether the aforementioned records should really be deleted or not to be of maximum benefit to Bitnami users? |
|
Hi @andrewpollock, Thanks for your message. Yes, it is ok to remove old/non-supported data from OSV.dev as we do in Bitnami's VulnDB. Let me give you more information on this. I have been checking the CVE files you mentioned and almost all of them belong to recently deprecated assets in our catalog that we no longer support. From time to time we deprecate one or more of our solutions due to different reasons, and in that situation, we keep its security information in our vulnerability database for a grace period of one month, as stated in our deprecation policy. Once that grace period is over, we remove the information from our database. The rest of the mentioned files and not belonging to deprecated assets were removed because they don't actually apply. For instance, the CVEs mentioned for WordPress and WordPress Multisite assets don't apply because they affect beta versions only. Hope this message helps to clarify our deprecation policy. Do not hesitate to ask any other questions you may have. |
|
Hi @andrewpollock, We are closing this ticket as solved. Thank you for reporting this issue on our database and for your help fixing it. Do not hesitate to open a new ticket with any other questions you may have or any other issues you may find. |
Title
CVE-2021-44528
What steps will reproduce the bug?
What is the expected behavior?
The version used passes SemVer validation
What do you see instead?
The version does not pass SemVer validation
Additional information
I have not exhaustively reviewed the remaining records to see how widespread this problem is.
Either the versions should be SemVer compliant, or the
ranges[].typeshould beECOSYSTEMThe text was updated successfully, but these errors were encountered: