Repository navigation
Replies: 3 comments
I don't think it's because the criteria is different, just because no one has done the legwork? @amousset looks like you started on this in rustsec/rustsec#656, but we don't have automation yet. Are you still planning on working on that? |
|
It would be awesome if it was possible to do that automatically in a reliable way, even if there's some loss of fidelity in the mirroring process. |
|
If it could look at the |
Uh oh!
There was an error while loading. Please reload this page.
Hi,
Browsing through some recent Rust crate CVE:s, I noticed that they weren't in the RustSec database. Looking deeper, I realized that it is not too uncommon for CVE:s to only be reported to the GitHub Advisory Database. Of course, there is an automatic import the other way, making the GitHub database a superset of of RustSec for Rust CVE:s.
Is this because the criteria are different or because the reporter/maintainer didn't create an entry in both advisory databases (or only in RustSec, relying on the import step)? I saw that this was noticed in #1711 (92 missing crates) a few years back, and I'm unsure if many of those advisories made it into RustSec.
Today at least, a crate passing
cargo auditdoesn't paint the full picture (which also affects sites like crates.io), and a tool like osv-scanner works more reliably. However, by relying on an online service instead of a locally cloned repo, that tool has other challenges.The RustSec database seems much better suited for offline operation (once you've pulled the repo), which makes it a pity that there is no automatic mirroring going the other way. Has there been any thought put into mirroring the Rust category from the GitHub advisory database to make RustSec the definitive Rust vulnerability database, or are there perhaps good reasons not to (besides the risk of creating an infinite duplication loop unless it is done properly)?
Kind regards,
/ David
All reactions