Skip to content
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

Merged
merged 8 commits into from
Aug 30, 2022

Conversation

pinkforest
Copy link
Contributor

@pinkforest pinkforest commented Aug 6, 2022

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 ago

Please review to make sure this is addressed e.g. potentially supressing / migration etc.

I've also added this into yaml:

    # Prevent sudden announcement of a new advisory from failing ci:
    continue-on-error: ${{ matrix.checks == 'advisories' }}

Note: Please review licenses

Cargo deny does license check and I had to add the ring crate specific license and Unicode unicode-ident as special cases

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • A changelog entry has been made in the appropriate crates - N/A

Copy link
Contributor

@thomaseizinger thomaseizinger left a 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"
Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Contributor Author

@pinkforest pinkforest Aug 17, 2022

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 ?

Copy link
Contributor

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.

@thomaseizinger
Copy link
Contributor

The actual issue is already being addressed: prometheus/client_rust#78

@thomaseizinger
Copy link
Contributor

Friendly note @pinkforest : We squash merge here and favor merges over force-pushes. Thank you :)

@pinkforest
Copy link
Contributor Author

pinkforest commented Aug 8, 2022

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 push -f

@pinkforest pinkforest mentioned this pull request Aug 8, 2022
Copy link
Member

@mxinden mxinden left a 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!

.github/workflows/cargo-audit.yml Outdated Show resolved Hide resolved
deny.toml Show resolved Hide resolved
# 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"
Copy link
Member

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.

@pinkforest
Copy link
Contributor Author

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

@pinkforest
Copy link
Contributor Author

pinkforest commented Aug 10, 2022

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

@mxinden
Copy link
Member

mxinden commented Aug 17, 2022

@pinkforest why do we need both cargo audit and cargo deny?

@pinkforest
Copy link
Contributor Author

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.

@thomaseizinger
Copy link
Contributor

thomaseizinger commented Aug 17, 2022

@pinkforest why do we need both cargo audit and cargo deny?

cargo deny doesn't open issues I think although we could potentially script that with the pre-installed gh CLI.

@thomaseizinger
Copy link
Contributor

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

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 cargo audit. We will still get the open issue and can prioritise work to fix them whilst being able to merge other PRs.

For cargo deny, we could remove the continue-on-error config and just not mark it as mandatory for merge.

@pinkforest
Copy link
Contributor Author

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.

Copy link
Member

@mxinden mxinden left a 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.

.github/workflows/cargo-deny-pr.yml Outdated Show resolved Hide resolved
Signed-off-by: pinkforest <36498018+pinkforest@users.noreply.github.com>
Comment on lines +15 to +18
matrix:
checks:
- advisories
- bans licenses sources
Copy link
Member

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?

Copy link
Contributor Author

@pinkforest pinkforest Aug 27, 2022

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.

Copy link
Contributor

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.

@thomaseizinger thomaseizinger changed the title Switch to cargo-deny GH action .github/workflows: Split advisory issues from PR workflows using cargo-deny Aug 29, 2022
@thomaseizinger
Copy link
Contributor

@mxinden @pinkforest I tried to summarize what this PR does in a new title. Improvements welcome!

Signed-off-by: pinkforest <36498018+pinkforest@users.noreply.github.com>
Copy link
Contributor

@thomaseizinger thomaseizinger left a 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

@thomaseizinger
Copy link
Contributor

@mxinden Feel free to merge if you also agree with the changes.

Copy link
Member

@mxinden mxinden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙏

@mxinden mxinden merged commit f16561c into libp2p:master Aug 30, 2022
@pinkforest pinkforest deleted the feat/switch/deny branch August 30, 2022 09:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants