Optional Dependencies

[guenhter]

Hi,

when I use a create in my library which has many optional features like sqlx (https://github.com/launchbadge/sqlx), and I create a sbom for my project, it also considers all the dependencies of the features which are actually not active.

Running cargo tree only lists the dependencies of activated features and lets the rest away. This would be very nice also to have for the sbom. For me personally this currently makes some problems because I process the sbom further (e.g. for vulnerability testing) and that one fails because of dependencies which are in actually not used by me.

It would be nice to consider those optional dependencies and filter them out in case they are not used.

[Shnatsel]

Hmm, we should have support for this already with --features flag to select the features of your project that will be considered active, and Cargo feature resolution should take it from there. If it doesn't, that's a bug.

Could you provide specific steps to reproduce the issue so I could investigate?

[guenhter]

Here are the steps to reproduce:

mkdir foo && cd foo

cargo init
cargo add sqlx --features sqlite

cargo tree | grep mysql
# No match because mysql is only an optional dependency of sqlx which is not activated here in foo

cargo cyclonedx
cat foo.cdx.xml | grep mysql
# It shows up here, even if the feature is not activated

[ssonthal]

Hey @guenhter/@Shnatsel

I was checking the cargo tree implementation to understand how are they handling such cases. Is that a good starting point to resolve this issue?

I have narrowed it down to this method -> https://github.com/rust-lang/cargo/blob/d8cb5fb7f8f66fc9b4ba3d80b089474164a8a83d/src/cargo/ops/resolve.rs#L137

Let me know your thoughts on this.

[Shnatsel]

cargo cyclonedx relies on cargo metadata because cargo tree does not provide a machine-readable output.

We should be passing the right feature combinations to cargo metadata for the top-level project. The first step would be investigating whether those superfluous dependencies show up in the output of cargo metadata.

Note that cargo metadata may over-include optional dependencies due to rust-lang/cargo#7754 and rust-lang/cargo#10718. These issues should be fixed in cargo metadata and it's difficult for us to do anything about that in cargo cyclonedx.

[ssonthal]

Okay so ideally this should be handled as part of cargo metadata. Understood. Is #760 intended to solve this?