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

Prevent Unable to locate valid bom ref for package error when using a range and there are multiple versions of a package referenced #903

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

tl-maisie-sadler
Copy link

Context

I have come across an issue while using this tool to generate an SBOM for one of our larger solutions.

When the following occurs:

  1. Package dependency is specified with range syntax, e.g. [1.4.0, 1.4.0]
  2. Multiple versions of the package referenced throughout the solution

We get an error message as below, even though there are packages available.

Unable to locate valid bom ref for TrueLayer.Observability.Abstractions [1.4.0, 1.4.0]

Solution

The proposed solution chooses the first referenced package, rather than assuming none exists if the found packages != 1.

@tl-maisie-sadler tl-maisie-sadler requested a review from a team as a code owner August 8, 2024 11:09
…re than one package references

Signed-off-by: Maisie Sadler <[email protected]>
Signed-off-by: Maisie Sadler <[email protected]>
@mtsfoni
Copy link
Contributor

mtsfoni commented Aug 8, 2024

The core issue is, that a c#-solution is not one software-solution (as in tool, library or service) but rather an arbitrary collection of one or more software-solution or parts of such.

The issue comes from the idea, that a software-solution can only have one version of a dependency at one time. Which is basically correct for C#.

This bases on the assumption that you would create a SBOM (in the context of this tool) for a single software-solution. Which makes sense.

Running this tool against a c#-solution, now assumes that multiple software-solution are actually just one because they are arbitrarily grouped, might find multiple dependencies with same name but different version - which basically is correct, because they are used in different software-solutions.

If one just discards all versions but the first, one creates an incomplete SBOM. In my opinion it's actually a flaw that you can run this tool against a .sln-file and I'd recommend running it against the root-component (.csproj) of each included software-solution separately and potentially - if necessary - merge them after. If the project uses PackageReferences inside the project file, transitive dependencies will be detected and resolved to the correct version.

The correct solution for this problem, would be, to simply add all versions of that library to the sbom, because all of them might be in use by some of the parts of the software solution. We can't easily know when creating a sbom for solutions.

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

Successfully merging this pull request may close these issues.

2 participants