-
Notifications
You must be signed in to change notification settings - Fork 5
Add cargo deny to audit licenses of dependencies #40
Conversation
140ccdf
to
02a6f2a
Compare
https://github.com/expressvpn/wolfssl-sys/actions/runs/6021857682/job/16335468877?pr=40 failed but CI shows passed -- I guess we need to propagate an error code or something? |
allow-registry = ["https://github.com/rust-lang/crates.io-index"] | ||
# List of URLs for allowed Git repositories | ||
allow-git = [ | ||
] |
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 you need to add the liboqs repo here -- or maybe we can switch back to the released version now that 0.8.0 is 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.
Yes makes sense to update the deps since its released last week.
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 switch back to using the crate now that it has been released. This is on my todo list for this week, but if you're already working in this area, feel free to make the 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.
It became chicken and egg problem when I tried to upgrade liboqs to 0.8.0
Issue:
The latest version of wolfssl v5.6.3 was released on June 21:
https://github.com/wolfSSL/wolfssl/releases/tag/v5.6.3-stable
But liboqs renamed some of its api's on May 17 in this pr:
open-quantum-safe/liboqs#1467
and released v0.8.0 on Aug 21
WolfSSL updated its api to accomodate the above rename in this pr only on July 12:
But it is not yet released.
So if we have to move liboqs to crates version, either we have to patch the wolfssl in build script or use the master version of wolfssl. Think we can take this up in future pr
This is actually a warning and But the run actually getting succeeding for me without any warnings locally (typical works for me scenario) |
Oh, I missed that. I think we should consider making most of these things actual errors, a warning hidden in a passing CI job noone will ever notice.
cargo deny fetch or cargo install -f cargo-deny are my usual "fix" when this sort of thing happens, CI naturally gets the very latest of everything. |
4aba2f0
to
ee7869c
Compare
Found the issue, the github run uses
|
ee7869c
to
197e8a0
Compare
197e8a0
to
d8ee113
Compare
- Add earthly target `check-license` for checking licenses - Update github actions to `cargo deny licenses sources bans` on every pr excluding advisories - Add github action nightly job to run `cargo deny` including advisories
d8ee113
to
f8aaa2d
Compare
Description
check-license
for checking licensescargo deny licenses sources bans
on every pr excluding advisoriescargo deny
including advisoriesMotivation and Context
Auditing workspace (and its dependency graph) for security issues, licensing and other issues using
cargo-deny
How Has This Been Tested?
Verified
cargo deny sources licenses
running successfully locallyTypes of changes
Checklist:
main