-
Notifications
You must be signed in to change notification settings - Fork 975
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
.github/workflows: Split advisory issues from PR workflows using cargo-deny
#2803
Conversation
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 am in favor of this.
# https://embarkstudios.github.io/cargo-deny/checks/bans/cfg.html | ||
[bans] | ||
# Lint level for when multiple versions of the same crate are detected | ||
multiple-versions = "warn" |
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'd love to ban this actually but I think that is gonna be a fair bit of work.
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.
Out of curiosity, where are we at today?
I think the best we can do is be a good citizen and merge @dependabot pull requests quickly.
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.
Out of curiosity, where are we at today?
Something like 20 duplicates I think.
I think the best we can do is be a good citizen and merge @dependabot pull requests quickly.
We can do better and regularly check for duplicate dependencies and investigate, where they come from. We can also audit, which dependencies we have and try to get rid of some. Another way is to audit for set but unused features or entire dependencies altogether.
For example, we pull in an old version of rand (0.7) via ed25519-dalek
.
Several of the windows specific dependencies are also duplicates I think.
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.
ed25519-dalek is not maintained.
and there is another concern about it which doesn't break anything but it's not good either
rustsec/advisory-db#1360
I don't think any of this stops this PR tho ?
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.
It doesn't no, sorry for the OT.
The actual issue is already being addressed: prometheus/client_rust#78 |
46eac3a
to
526ff8d
Compare
Friendly note @pinkforest : We squash merge here and favor merges over force-pushes. Thank you :) |
Oh that was just github's catch-up rebase, didn't want to bother with merge from main commits noise - but noted thanks :) p.s. needs CONTRIBUTING.md 🤷♀️ EDIT: p.p.s. a CONTRIBUTING.md I eventually found - https://github.com/ipfs/community/blob/master/CONTRIBUTING.md#rebasing instructs |
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.
Thanks @pinkforest and @thomaseizinger for the help on this!
# https://embarkstudios.github.io/cargo-deny/checks/bans/cfg.html | ||
[bans] | ||
# Lint level for when multiple versions of the same crate are detected | ||
multiple-versions = "warn" |
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.
Out of curiosity, where are we at today?
I think the best we can do is be a good citizen and merge @dependabot pull requests quickly.
multiple-versions - I didn't get any warnings but there are some weird SemVer stuff that sometimes it's impossible to deal with so it's best to leave as warn - reality of dealing with rust ecosystem. I will send a commit around getting the separate cron-check for advisories and will separate it from the PR CI workflow |
I just switched the PR to be different flow with deny from periodic one that uses audit The periodic will catch any advisories and beep about them as usual and the PR / push will catch license / shady dependencies |
@pinkforest why do we need both |
Audit is for the advisories on scanning periodically. Deny is for the PR scanning which includes license checks. As you can see other is on PR / push and the other one is for cron basis. It's better to use both. |
|
Thanks! Can we split this PR into two then? Changing cargo audit to only run on a schedule and using cargo deny are two different things IMO. I think the latter is pretty uncontroversial whereas the former may need a bit of discussion. I am okay with moving away from a PR-based audit with For |
I am not changing your existing cargo audit except modifying it to exclude PR pushes which is being switched to cargo deny. So I don't think there is much to gain to separate PRs at this point. Happy to take the continue-on-error out. |
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.
One comment. Otherwise looks good to me. In the future, agreed with Thomas that separate pull requests are easier.
Signed-off-by: pinkforest <[email protected]>
matrix: | ||
checks: | ||
- advisories | ||
- bans licenses sources |
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.
Given that we no longer treat advisories
special, is the matrix still needed? Also do we need to list the commands any longer at all? Wouldn't a cargo deny check
suffice to run them all?
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 personally prefer to be explicit as if there is change in the future you can gradually adopt more check features.
If the preference is to be implicit non-exhaustive then we can change this but prepare for surprise(s) if the tooling changes.
Also I personally prefer matrix to separate the workflow streams so I can catch / view errors in context e.g. I want to have different mindset when dealing with licenses vs advisories - plus it's faster as silver lining.
If the preference is to bundle them to same flow then that can be certainly changed.
Let me know and I can change.
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'd like to keep it separate actually so we can temporarily ignore a failing advisory check for example. It also allows us to mark some of them as required via GH for merging and leave others optional.
cargo-deny
@mxinden @pinkforest I tried to summarize what this PR does in a new title. Improvements welcome! |
Signed-off-by: pinkforest <[email protected]>
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.
LGTM! Thanks for the contribution and sorry for the delay in getting this reviewed1
@mxinden Feel free to merge if you also agree with the changes. |
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.
🙏
Description
actions-rs/check-audit is not maintained
Links to any relevant issues
rust-secure-code/wg#46
Open Questions
It is currently complaining about
owning_ref
- we added advisory few days agoPlease review to make sure this is addressed e.g. potentially supressing / migration etc.
I've also added this into yaml:
Note: Please review licenses
Cargo deny does license check and I had to add the
ring
crate specific license and Unicodeunicode-ident
as special casesChange checklist