Use cargo SBOM precursor files, if available

[tofay]

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.

Closes #192

Slightly interestingly, cargo didn't include build dependencies for the test fixtures unless I added a build.rs files.

[Shnatsel]

Thanks a lot! I'll take a closer look in the next few days.

Slightly interestingly, cargo didn't include build dependencies for the test fixtures unless I added a build.rs files.

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?

[tofay]

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.

[Shnatsel]

Ah, you are probably right! I am a little rusty on the finer points of Cargo dependencies.

[Shnatsel]

I've only done a cursory look so far - it's a really hot day, sorry 😅

By and large this looks great! I've noted some nits, and I'll take a closer look at the format transformation algorithm in the next few days.

Thanks again!

[Shnatsel]

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.

[tofay]

Yeah I was going to ask about this, all 400 lines of cargo.lock additions are from this dep

[tofay]

Most of the new dependencies result from cargo-util-schemas depending on url, which is necessary to parse the package id spec that is part of the SBOM precursor. So I suggest we just keep the dependency here?

Since cargo-util-schemas is a dependency of cargo, any company that is reviewing all its dependencies will already depend on some versions of the new deps via cargo anyway.

[Shnatsel]

Do we really need to parse the package ID spec with the full generality of URLs?

Can we use either a stripped-down version of URL crate with all the fancy features disabled, or just rely on the crate names being ASCII without weird characters?

Also, if the package ID spec cannot be treated as mostly opaque and we need the full generality of the URL crate to actually parse it, that's an issue with the format that I'd like to get fixed before it's stabilized.

[Shnatsel]

Okay, I think I found an actual bug in Cargo: if I run cargo +nightly build -Z sbom --release and then CARGO_BUILD_SBOM=true cargo +nightly build -Z sbom --release, the SBOM file will not be actually generated. It seems that whether the SBOM should be built or not is not part of the check for whether a rebuild is necessary or not.

[tofay]

Okay, I think I found an actual bug in Cargo: if I run cargo +nightly build -Z sbom --release and then CARGO_BUILD_SBOM=true cargo +nightly build -Z sbom --release, the SBOM file will not be actually generated. It seems that whether the SBOM should be built or not is not part of the check for whether a rebuild is necessary or not.

Raised at rust-lang/cargo#15695