8000 Conan cataloger: distinquish normal and build requirements - might be relevant for other catalogers as well (e.g. NPM) · Issue #3386 · anchore/syft · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Conan cataloger: distinquish normal and build requirements - might be relevant for other catalogers as well (e.g. NPM) #3386

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.

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom
Open
jngrb opened this issue Oct 25, 2024 · 3 comments
Open

Conan cataloger: distinquish normal and build requirements - might be relevant for other catalogers as well (e.g. NPM) #3386

jngrb opened this issue Oct 25, 2024 · 3 comments
Labels
enhancement New feature or request needs-proposal Should be done but needs proposal/design for further discussion

Comments

@jngrb
Copy link
jngrb commented Oct 25, 2024 •
edited
Loading

What would you like to be added:

The Conan cataloger #1083 which indexes conan.lock files (conan v1 or conan v2 #2461) should distinquish regular requirements and build requirements with a certain CycloneDX attribute, e.g.

cdx:composer:package:isDevRequirement

as specified here:

https://github.com/CycloneDX/cyclonedx-property-taxonomy/blob/main/cdx/composer.md

And for SPDX, the relationship type should be set.

Currently, both dependencies of both requirements types are listed indistinguishable.

(My primary use case is Conan v1 and v2 and the CycloneDX format.)

Specific problem / bug:

When a certain Conan recipe is both a requirement and a build requirement, generating the SBOM via syft results in duplicated entries. As an effect, the produced SBOM file cannot be loaded anymore in other applications due to a cyclonedx.exception.model.UnknownComponentDependencyException.

Why is this needed:

The goal is a final BOM can be parsed for "productive" dependencies (usually deployed to consumers) and "build tool" requirements (only part of the build environment).

Also to exception for duplicated entries should be avoided.

Additional context:

Other cataloger do this for NPM as well: cyclonedx-node-npm already does this and Yarn intends to do it as well: CycloneDX/cyclonedx-node-yarn#51 - however, they have their own property cdx:npm:package:development

But in syft, the NPM cataloger ignores the "devDependencies" flag both relation ship types end up in the SBOM without being distinquished - just as for Conan.

An alternative strategy might be that there is an global option (or CLI flag) to include build/dev requirements (or not) - in the same ways the glob parameter could be made configurable for Conan, cf. #1854

Minimal example:

Conan file:

from conan import ConanFile

class ExampleOpenSsslRecipe(ConanFile):
    settings = "os", "compiler", "build_type", "arch"
    generators = "CMakeToolchain", "CMakeDeps"

    def requirements(self):
        # we need the openssl libraries during runtime
        # to load and process cryptographic keys
        self.requires("openssl/3.2.1")

    def build_requirements(self):
        # we need openssl.exe during build process
        # to generate cryptographic keys
        self.tool_requires("openssl/3.2.1")

Using Conan v1 and using a dummy cross-compile environment, conan install -pr:h default -pr:b default . produces the conan.lock file attached. (My real use case is a much more complicated cross-compilation where the build and host profiles differ significantly.)

Using syft scan . I get the sbom json file attached. This file, I cannot upload e.g. to DependencyTrack as interpreting it fails with the mentioned exceptions.

minimal_sbom_example.zip
@jngrb jngrb added the enhancement New feature or request label Oct 25, 2024
@jngrb
Copy link
Author
jngrb commented Oct 25, 2024

There is a relationship to "relationships in SBOMS" #572 and likely to "duplicated NPM entries" #2559

@kzantow
Copy link
Contributor
kzantow commented Oct 29, 2024

I think it's a great idea to be able to appropriately identify relationships as development/build/test/etc. vs. those included at runtime. You've referenced the right issues already (another is #3130).

I believe the correct way to do this is to define new relationship types, probably analogous to those defined in SPDX for build-time dependencies and perhaps other scopes as appropriate, and update the catalogers to return appropriate relationships to these dependencies. However, this does not map nicely to CycloneDX -- since this is a component property. What happens in the event that there are multiple instances of the same package with different qualifiers? Is there some way to model this in CycloneDX in a way that would support multiple components and each has the properties appropriately set without resulting in duplicate packages? Any suggestions how to handle this consistently would be much appreciated!

@kzantow kzantow added needs-proposal Should be done but needs proposal/design for further discussion and removed needs-discussion labels Jan 23, 2025
@kzantow kzantow moved this to Backlog in OSS Jan 23, 2025
@kzantow
Copy link
Contributor
kzantow commented Jan 23, 2025

Notes from livestream: we definitely want to be able to represent build/dev/etc. dependencies appropriately -- we just need a proposal for the details and/or implementation to discuss further, which should address how this is represented in Syft's relationships (is this just a different dependency type? another qualifier on the dependency? do we duplicate other relationships so "all dependencies" are represented directly in the SBOM? etc.).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request needs-proposal Should be done but needs proposal/design for further discussion
Projects
OSS
Status: Backlog
Milestone
No milestone
Development

No branches or pull requests
2 participants
@kzantow @jngrb
0