OSV export #366
OSV export #366
Conversation
…olidated rustsec repo
|
Let me know if you'd prefer to keep the PR in draft or close it to avoid the cost of running CI on every commit. |
|
It's fine to keep it open |
Merge commit 'fb90dae1947a2607a30de774a4da7e503e0d6669' into osv
… representation and an implementation detail
…orarily for testing purposes)
My implementation of the 'modified' field was determined to be spec-compliant
| let commit_id = commit_id?; | ||
| let commit = repo.find_commit(commit_id)?; | ||
| // Ignore merge commits (2+ parents) because that's what 'git whatchanged' does. | ||
| // Ignore commit with 0 parents (initial commit) because there's nothing to diff against |
There was a problem hiding this comment.
Would that also mean that if a file is touched only in the initial commit it would be missing entirely? Could that be relevant to the generated advisory output in the form of a missing advisory?
Asked differently, would it hurt to diff against an empty tree (None) in that case to also fetch these paths just in case?
There was a problem hiding this comment.
In the general case you're probably right, but this is not relevant for the advisory database which was initialized with a README, and which has been touched since.
There was a problem hiding this comment.
I'll add this in a follow-up PR so that the code is future-proof, e.g. in case we decide to flatten the repo history. Thanks for bringing this up!
There was a problem hiding this comment.
I've opened #440 to address this. Thanks again!
…endly; this follows the same pattern set by the `web` subcommand
| @@ -44,6 +45,7 @@ fix = ["cargo-edit"] | |||
| git = ["crates-index", "git2", "home", "humantime", "humantime-serde"] | |||
| dependency-tree = ["cargo-lock/dependency-tree"] | |||
| vendored-openssl = ["git2/vendored-openssl"] | |||
| osv-I-know-this-is-unstable = ["git", "chrono"] | |||
There was a problem hiding this comment.
Perhaps simply osv suffices here, and you can leave a comment regarding stability?
There was a problem hiding this comment.
The format itself is not stabilized. I explicitly wanted to mark anything exporting to not-yet-finalized format as unstable, because it's not really exporting to OSV, it's exporting to a pre-release of OSV.
Also, renaming it to osv later will make it clear if e.g. some dependent code has been updated to the stable version or not. Not just the stable version of the code, but also the format.
This PR implements export from RustSec TOML format to the JSON-based format defined by https://github.com/google/osv
The implementation is feature-complete. The generated JSON has been successfully imported by OSV. See here for what the exported data looks like.
Summary of the changes:
"> 2.0.0", "<= 2.5"or"^1.5"to version ranges, seeOsvRangestruct. This is required for OSV export.Advisoryto data structures isomorphic to OSV JSON, which can be serialized withserde_json.modifiedfield; seeGitModificationTimesstruct.withdrawnfield to RustSec advisory format, which must be set to a date. This is required for exporting to OSV. Updated the linter to require this field to be present ifyanked = true. This is a breaking change under semantic versioning and caused a version bump.Versionsstruct to validate range consistency on creation, so we don't have to check for inconsistent ranges in every single function dealing with them.rustsec-admin osvCLI command for exporting the RustSec TOML to OSV JSON.Remaining merge blockers:
Remaining blockers for deploying continuous export to OSV:
rustsec-admin osv- implemented herewithdrawnfield to the production advisory DB: Addwithdrawnfield advisory-db#942