bom SPDX relationships like `DEPENDENCY_OF` and `TEST_DEPENDENCY

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 [email protected]
  │ 
  │ 📦 DESCRIBES 1 Packages
  │ 
  ├ [email protected]
  │  │ 🔗 2 Relationships
  │  ├ HAS_PREREQUISITE PACKAGE [email protected]
  │  └ DEPENDS_ON PACKAGE [email protected]
  │ 
  └ 📄 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 [email protected]
  │ 
  │ 📦 DESCRIBES 1 Packages
  │ 
  ├ [email protected]
  │  └ 🔗 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.

Oct 08 '23 09:10 maxhbr

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.

Oct 09 '23 20:10 goneall

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.

Oct 12 '23 13:10 zvr

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

Nov 28 '23 10:11 maxhbr

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

This bot triages un-triaged 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:

Mark this issue as fresh with /remove-lifecycle stale
Close this issue with /close
Offer to help out with Issue Triage

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

/lifecycle stale

Feb 26 '24 11:02 k8s-triage-robot

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:

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:

Mark this issue as fresh with /remove-lifecycle rotten
Close this issue with /close
Offer to help out with Issue Triage

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

/lifecycle rotten

Mar 27 '24 12:03 k8s-triage-robot

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

Mar 27 '24 12:03 maxhbr

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

Mar 27 '24 12:03 cpanato

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

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

/close not-planned

Apr 26 '24 13:04 k8s-triage-robot

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

In response to this:

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

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

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Apr 26 '24 13:04 k8s-ci-robot

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

What happened:

Variant 1

Variant 2

What you expected to happen: