advisory-database
advisory-database copied to clipboard
github
Ecosystem field unclear for things that are not npm/rust/...
Hi,
I just found out the ecosystem thingy is mandatory to put in affected versions. Is there a reason/need behind that? Because for example, WordPress plugins are in the database, but you can't use the form for them as WordPress is not in the predefined ecosystem fields. The same goes for GHSA-gqhp-5j32-xwmm which is a nodejs issue which doesn't fall into an ecosystem that is predefined. There are probably also plenty of other examples.
I am mainly wondering about the reason why it is mandatory, as I think having typed version ranges alone are also very helpful in case anyone wants to use the database for a tool. However, typed versions seem impossible without the ecosystem at this time.
As an example, this is in my opinion valuable to have but is not possible to get submitted:
Addition: It seems this comes from https://ossf.github.io/osv-schema/#affectedpackage-field however my question still stands as I think packages like nodejs should still be able to have typed versions.
I have been wondering this as well. For instance the Rust Advisory Database has reports for vulnerabilities in the rust toolchain itself separately from rust crates. It feels like this should be a separate ECOSYSTEM to crates.io. I suspect it makes sense to raise an issue about this up on the OSV Schema repo.
cc: @oliverchang
@MTRNord and @westonsteimel thanks so much for chiming in on these. This is indeed an issue we want to eventually address.
The reason that the ecosystem is required is that we have a highly-trained Curation team who is reviewing each PR and we want to make sure they're empowered to make decisions by working on the ecosystems we're familiar with. So at this point, we're only taking contributions on advisories that are part of our 8 formally supported ecosystems. I can see a possible future where we also take community contributions on non-supported ecosystems, but we have a lot of thinking to do on how to structure that.
I'd love to learn more about your use case.
Would either or both of you be interested in chatting with me for 30 minutes in the next month via Zoom? If so, please follow the link below to schedule a time that works best for us both. In recognition of your time, we’ll send you a $60 gift card/cash card/credit for the GitHub Swag store.
https://calendly.com/security-advisories-ux-calls/25min?back=1&month=2021-10
@MTRNord and @westonsteimel thanks so much for chiming in on these. This is indeed an issue we want to eventually address.
The reason that the ecosystem is required is that we have a highly-trained Curation team who is reviewing each PR and we want to make sure they're empowered to make decisions by working on the ecosystems we're familiar with. So at this point, we're only taking contributions on advisories that are part of our 8 formally supported ecosystems. I can see a possible future where we also take community contributions on non-supported ecosystems, but we have a lot of thinking to do on how to structure that.
I'd love to learn more about your use case.
Would either or both of you be interested in chatting with me for 30 minutes in the next month via Zoom? If so, please follow the link below to schedule a time that works best for us both. In recognition of your time, we’ll send you a $60 gift card/cash card/credit for the GitHub Swag store.
https://calendly.com/security-advisories-ux-calls/25min?back=1&month=2021-10
Hi :)
I don't yet have an actual use case here. This mainly came up in the first few minutes of scrolling through the list as I saw the NodeJS and a few WordPress plugin issues. As the NodeJS one had the versions in the text, it was easy to fill the form to give the thing a try :)
The thing with having it "typed"/machine-readable is simply that past taught me that there tend to be plenty of OSS people that tend to make awesome stuffs like statistics out of this kind of data. And having this data flawed just feels kind of sad as there would be plenty of data missing due to this restriction as there seem to be quite a lot of things that don't fall into the existing ecosystems. So this for me is more a thing that would help for future use cases than having an actual use case yet. :)
@MTRNord thanks for the response, this is great feedback and we'll keep an eye on this issue as more feedback comes in.
I have been wondering this as well. For instance the Rust Advisory Database has reports for vulnerabilities in the rust toolchain itself separately from rust crates. It feels like this should be a separate ECOSYSTEM to
crates.io. I suspect it makes sense to raise an issue about this up on the OSV Schema repo.cc: @oliverchang
I believe the Rust advisory database only reports crates vulnerabilities in OSV format. @Shnatsel to comment. Should we also export the toolchain vulnerabilities (and use a separate ecosystem?)"
I believe the Rust advisory database only reports crates vulnerabilities in OSV format.
Yes, that is correct.
Should we also export the toolchain vulnerabilities (and use a separate ecosystem?)
I believe a separate ecosystem is indeed necessary, because Cargo exists both as a crate with its own version (currently 0.60.0) and is also bundled the Rust toolchain with a specific version (currently 1.59.0), and it's the toolchain version that we track in the toolchain advisories. Attempting to match it on the crate version will silently give you incorrect results.
That said, that particular part of the database is currently a preview, for two reasons:
- We don't yet have first-party tooling that takes advantage of toolchain vulnerability data, so we have no real-world experience with it.
- Right now our format assumes that toolchain vulnerabilities have a CVE IDs assigned; this assumption has been violated already, so a change to our internal format will probably be required. (We did try to become a CNA, but ended up stepping on the toes of Rust Foundation and the process has stalled).
