Use cargo SBOM precursor files, if available #213
Conversation
If cargo sbom function is enabled, cargo-auditable will read the SBOM precursor file and use it to generate dependency information rather than trying to use the `cargo metadata` command.
|
Thanks a lot! I'll take a closer look in the next few days.
Looks like a bug in Cargo's SBOM support. I don't think we can actually ship with a bug like that. @arlosi are you aware of this issue? Should we file a bug upstream against Cargo? |
|
Isn't that a case of cargo being more accurate than cargo metadata? Without a build.rs, a crate can have no build dependencies, regardless of what is declared in Cargo.toml. |
|
Ah, you are probably right! I am a little rusty on the finer points of Cargo dependencies. |
| let version_info = if sbom_path.as_ref().map(|p| !p.is_empty()).unwrap_or(false) { | ||
| let sbom_paths = std::env::split_paths(&sbom_path.unwrap()).collect::<Vec<_>>(); | ||
| // Cargo may create multiple SBOM precursor files. | ||
| // We can't control per-binary (or cdylib) dependency information, just grab the first non-rlib SBOM we find. |
There was a problem hiding this comment.
If I recall correctly, this is only reached when running a rustc command to compile a specific crate. Since dependencies are crate-wide, but a crate can have multiple targets (rlib, bin, cdylib, etc) it shouldn't really matter which SBOM we find - they should all contain identical dependency trees.
If I'm mistaken, I'd really like to know about that. And if my understanding is correct, we should include this as a comment.
There was a problem hiding this comment.
Does cargo emit an SBOM file per-target or per-binary? A single lib target can result in multiple binaries for each different specified library crate type through a single rustc invocation.
| // cargo sbom data format has more nodes than the auditable info format - if a crate is both a build | ||
| // and runtime dependency it will appear twice in the `crates` array. | ||
| // The `VersionInfo` format lists each package only once, with a single `kind` field | ||
| // (Runtime having precence over other kinds). |
There was a problem hiding this comment.
| // (Runtime having precence over other kinds). | |
| // (Runtime having precedence over other kinds). |
| @@ -21,6 +21,7 @@ cargo_metadata = "0.18" | |||
| pico-args = { version = "0.5", features = ["eq-separator", "short-space-opt"] } | |||
| serde = "1.0.147" | |||
| wasm-gen = "0.1.4" | |||
| cargo-util-schemas = "0.8.1" | |||
There was a problem hiding this comment.
This pulls in a really sprawling dependency tree. If we're only using two structs from it anyway, I'd prefer to just copy-paste their definitions and avoid this massive dependency bloat.
cargo auditable is meant to be used by companies too, and I shudder at the thought of dragging all that through a security review.
There was a problem hiding this comment.
Yeah I was going to ask about this, all 400 lines of cargo.lock additions are from this dep
|
Okay, I think I found an actual bug in Cargo: if I run |
If cargo sbom function is enabled, cargo-auditable will read the SBOM precursor file and use it to generate dependency information rather than trying to use the
cargo metadatacommand.Closes #192
Slightly interestingly, cargo didn't include build dependencies for the test fixtures unless I added a build.rs files.