Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optional Dependencies #766

Open
guenhter opened this issue Sep 30, 2024 · 5 comments
Open

Optional Dependencies #766

guenhter opened this issue Sep 30, 2024 · 5 comments

Comments

@guenhter
Copy link

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
Copy link
Contributor

Shnatsel commented Oct 5, 2024

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
Copy link
Author

guenhter commented Oct 7, 2024

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
Copy link

ssonthal commented Nov 9, 2024

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
Image

Let me know your thoughts on this.

@Shnatsel
Copy link
Contributor

Shnatsel commented Nov 9, 2024

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
Copy link

ssonthal commented Nov 9, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants