search

kubernetes-sigs / bom

A utility to generate SPDX-compliant Bill of Materials manifests
https://kubernetes-sigs.github.io/bom/
Apache License 2.0
329 stars 48 forks source link

SPDX relationships like `DEPENDENCY_OF` and `TEST_DEPENDENCY_OF` seem to be not supported #354

Closed maxhbr closed 4 months ago

maxhbr commented 11 months ago

There are some Relationships like TEST_DEPENDENCY_OF are pointing from the test dependency. These relationships are not represented and visualized correctly. Especially, if some SPDX document prefers DEPENDENCY_OF over DEPENDS_ON, it might be listed as having no relationships.

What happened:

As discussed in https://github.com/npm/cli/issues/6867#issuecomment-1751871862 the following two sections from SPDX documents are equivalent but yield different representations in this tool.

Variant 1
"relationships": [
  {
    "spdxElementId": "SPDXRef-DOCUMENT",
    "relatedSpdxElement": "SPDXRef-Package-hello-world-1.0.0",
    "relationshipType": "DESCRIBES"
  },
  {
    "spdxElementId": "SPDXRef-Package-hello-world-1.0.0",
    "relatedSpdxElement": "SPDXRef-Package-ms-2.1.3",
    "relationshipType": "HAS_PREREQUISITE"
  },
  {
    "spdxElementId": "SPDXRef-Package-hello-world-1.0.0",
    "relatedSpdxElement": "SPDXRef-Package-ci-info-3.9.0",
    "relationshipType": "DEPENDS_ON"
  }
]

visualized as

$ bom document outline ./spdx.json       
               _      
 ___ _ __   __| |_  __
/ __| '_ \ / _` \ \/ /
\__ \ |_) | (_| |>  < 
|___/ .__/ \__,_/_/\_\
    |_|               

 📂 SPDX Document hello-world@1.0.0
  │ 
  │ 📦 DESCRIBES 1 Packages
  │ 
  ├ hello-world@1.0.0
  │  │ 🔗 2 Relationships
  │  ├ HAS_PREREQUISITE PACKAGE ms@2.1.3
  │  └ DEPENDS_ON PACKAGE ci-info@3.9.0
  │ 
  └ 📄 DESCRIBES 0 Files
Variant 2
"relationships": [
  {
    "spdxElementId": "SPDXRef-DOCUMENT",
    "relatedSpdxElement": "SPDXRef-Package-hello-world-1.0.0",
    "relationshipType": "DESCRIBES"
  },
  {
    "spdxElementId": "SPDXRef-Package-ms-2.1.3",
    "relatedSpdxElement": "SPDXRef-Package-hello-world-1.0.0",
    "relationshipType": "PREQUISITE_FOR"
  },
  {
    "spdxElementId": "SPDXRef-Package-ci-info-3.9.0",
    "relatedSpdxElement": "SPDXRef-Package-hello-world-1.0.0",
    "relationshipType": "DEPENDENCY_OF"
  }
]

visualized as

$ bom document outline ./spdx.json
WARN 2 packages could not be assigned to the SBOM 
               _      
 ___ _ __   __| |_  __
/ __| '_ \ / _` \ \/ /
\__ \ |_) | (_| |>  < 
|___/ .__/ \__,_/_/\_\
    |_|               

 📂 SPDX Document hello-world@1.0.0
  │ 
  │ 📦 DESCRIBES 1 Packages
  │ 
  ├ hello-world@1.0.0
  │  └ 🔗 0 Relationships
  └ 📄 DESCRIBES 0 Files

What you expected to happen:

As they are describing the equivalent graph I would expect both to have similar representations in the tool. But the tool fails to identify that the second one has relationships at all.

There are some which could just be "normalized" on parsing, e.g. a DEPENDENCY_OF relationship could be converted to its DEPENDS_ON representation.

Some other types have no inverse, like BUILD_DEPENDENCY_OF, DEV_DEPENDENCY_OF, OPTIONAL_DEPENDENCY_OF, PROVIDED_DEPENDENCY_OF and TEST_DEPENDENCY_OF. For those there should be a way to show arrows which are pointing from the "smaller" to the "bigger". Maybe by introducing names for the inverse or with some ASCII art.

goneall commented 11 months ago

I agree tools should support the inverse direction for relationships in the parsing tools.

There are scenarios where the inverse relationship is created since the relationship is not known when the first component is created making it more convenient to add the reverse relationship to the second component rather than amending the first.

In the case of no inverse relationships - I personally think it would be OK if the tool just output a relationship type that isn't in the spec, but makes sense - e.g. BUILD_DEPENDS_ON for BUILD_DEPENDENCY_OF.

zvr commented 11 months ago

Another reason to support reverse relationships is preparing for the future: SPDXv3 removes the "dual" relationships. There is still a DEPENDS_ON but no more DEPENDENCY_OF, for example. Having both would unnecessarily complicate things, as there are (till now) 64 relationship types and we don't want to have 64 reverse ones.

maxhbr commented 9 months ago

ping @puerco , can you please chime in here and clarify your opinion on the ticket?

k8s-triage-robot commented 6 months ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot commented 5 months ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

maxhbr commented 5 months ago

Hey, I think this is still valid. Can someone please have a look?

cpanato commented 5 months ago

@maxhbr yep seems valid, are you willing to open a pr to get this fixed?

k8s-triage-robot commented 4 months ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

k8s-ci-robot commented 4 months ago

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to [this](https://github.com/kubernetes-sigs/bom/issues/354#issuecomment-2079387669): >The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. > >This bot triages issues according to the following rules: >- After 90d of inactivity, `lifecycle/stale` is applied >- After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied >- After 30d of inactivity since `lifecycle/rotten` was applied, the issue is closed > >You can: >- Reopen this issue with `/reopen` >- Mark this issue as fresh with `/remove-lifecycle rotten` >- Offer to help out with [Issue Triage][1] > >Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). > >/close not-planned > >[1]: https://www.kubernetes.dev/docs/guide/issue-triage/ Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.