3 ms·

This makes sense to me. I guess I'll start hunting for the equivalent of `govulncheck` for Rust/Cargo. Separately, I love the idea of the `geomys/sandboxed-ste

This makes sense to me. I guess I'll start hunting for the equivalent of `govulncheck` for Rust/Cargo. Separately, I love the idea of the `geomys/sandboxed-step` action, but I've got such an aversion to use anyone else's actions, besides the first-party `actions/*` ones. I'll give sandboxed-step a look, sounds like it would be a nice thing to keep in my toolbox.

FiloSottile 8mo ago
> I've got such an aversion to use anyone else's actions, besides the first-party `actions/*` ones Yeah, same. FWIW, geomys/sandboxed-step goes out of its way to use the GitHub Immutable Releases to make the git tag hopefully actually immutable.
bpavuk 8mo ago
> I guess I'll start hunting for the equivalent of `govulncheck` for Rust/Cargo. how about `cargo-audit`?
- mirashii 8mo ago
  cargo-audit is not quite at an equivalent level yet, it is lacking the specific features discussed in the post that identify the vulnerable parts of the API surface of a library. cargo-audit is like dependabot and others here in that it only tells you that you're using a version that was vulnerable, not that you're using a specific API that was vulnerable.
  - hobofan 8mo ago
    Saddly, since it relies on a Cargo.lock to be correct it also is affected by bugs that place dependencies in the Cargo.lock, but are not compiled into the binary. e.g. weak features in Cargo currently cause unused dependencies to show up in the Cargo.lock.
conradludgate 8mo ago
https://rustsec.org/ https://rustsec.org/
- LawnGnome 8mo ago
  Although, unfortunately, not all RustSec advisories include function-level vulnerability metadata in practice.
LawnGnome 8mo ago
I was actually working on this last week, funnily enough. I've been working on a capability analysis tool for Rust, and if you're already generating a call graph via static analysis, taking that and matching it against the function-level vulnerability data that exists in RustSec isn't that hard. Hopefully I'll have something out next week.

FiloSottile 8mo ago

> I've got such an aversion to use anyone else's actions, besides the first-party `actions/*` ones Yeah, same. FWIW, geomys/sandboxed-step goes out of its way to use the GitHub Immutable Releases to make the git tag hopefully actually immutable.

bpavuk 8mo ago

> I guess I'll start hunting for the equivalent of `govulncheck` for Rust/Cargo. how about `cargo-audit`?

mirashii 8mo ago
cargo-audit is not quite at an equivalent level yet, it is lacking the specific features discussed in the post that identify the vulnerable parts of the API surface of a library. cargo-audit is like dependabot and others here in that it only tells you that you're using a version that was vulnerable, not that you're using a specific API that was vulnerable.
- hobofan 8mo ago
  Saddly, since it relies on a Cargo.lock to be correct it also is affected by bugs that place dependencies in the Cargo.lock, but are not compiled into the binary. e.g. weak features in Cargo currently cause unused dependencies to show up in the Cargo.lock.

conradludgate 8mo ago

https://rustsec.org/ https://rustsec.org/

LawnGnome 8mo ago
Although, unfortunately, not all RustSec advisories include function-level vulnerability metadata in practice.

LawnGnome 8mo ago

I was actually working on this last week, funnily enough. I've been working on a capability analysis tool for Rust, and if you're already generating a call graph via static analysis, taking that and matching it against the function-level vulnerability data that exists in RustSec isn't that hard. Hopefully I'll have something out next week.