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

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

Open
jngrb opened this issue Oct 25, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@jngrb
Copy link

jngrb commented Oct 25, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: No status
Development

No branches or pull requests

1 participant