-
Notifications
You must be signed in to change notification settings - Fork 49
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
Add a cargo deny workflow #89
Conversation
Also trims out a pointless submodule checkout (we have none).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to ADD this TOML in the dockerfile for Serai so that it copies the deny and for other services as well. Maybe concern here is only running the action workflow, but we want it to trigger for local builds too.
ADD deny.toml .
db-path = "~/.cargo/advisory-db" | ||
db-urls = ["https://github.com/rustsec/advisory-db"] | ||
|
||
vulnerability = "deny" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add a security threshold so this doesn't trigger on every little thing. Medium?
Threshold for security vulnerabilities, any vulnerability with a CVSS score lower than the range specified will be ignored. Note that ignored advisories will still output a note when they are encountered.
- None - CVSS Score 0.0
- Low - CVSS Score 0.1 - 3.9
- Medium - CVSS Score 4.0 - 6.9
- High - CVSS Score 7.0 - 8.9
- Critical - CVSS Score 9.0 - 10.0
severity-threshold =
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not against this but I'd rather have the heads up so we can review it ourselves and then make a new commit explicitly allowing it. I will note the CI doesn't even run advisory checks right now for this reason, but I currently lean towards having it check everything and doing the aforementioned solution, having given it a second thought. Will reach out off GitHub to discuss.
"RUSTSEC-2020-0071", # https://github.com/chronotope/chrono/issues/602 | ||
] | ||
|
||
[licenses] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we want private = { ignore = true }
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. That skips the entire tree for every unpublished crate. That means we wouldn't review our crates, nor Substrate, nor Substrate's depends.
Also this does not do deep scanning and relies on the author to be honest about licensing. If the lib uses embedded libs, we also rely on the author to do the appropriate thing for supplying the license. May not be relevant at this point, but if we want deeper scanning in the future we should look at https://github.com/EmbarkStudios/cargo-about. |
Placing this in the Dockerfile isn't helpful, unless the Dockerfile then runs We have clarifications available in cargo deny, and there's some level of LICENSE detection, but you're right it can misrepresented. I'm not sure |
While this may bring down an unrelated commit, we can manually review, before creating a followup commit allowing it. If it's critical, then this did its job.
Also trims out a pointless submodule checkout (we have none).
Relevant to #81 and #82.