You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just to be clear, this is about "packages of an SBOM", not PURLs.
While working on some test cases, I noticed two odd things:
The operation to return "all packages related to the SBOM root" returns a duplicate package
The operation to return "all packages related to the SBOM root" returns packages which are not at the root level of the package
The first
The first issue seems easy. Packages are found by relationships, and if the same package is found multiple times through that, then this will translate into multiple packages.
As the information of e.g. the relationships type is dropped at some point, it's no longer clear that was the case:
Just filtering out those duplicate packages at a later time won't work, as that might have an impact on pagination. Right now, that's not a problem. So we could commit to doing just that.
Otherwise there needs to be a way to search for relationships (returning that info), vs search for packages (which doesn't).
The second
The second issue is a bit trickier.
The idea of the SbomPackageReference::Root was to target all packages which are "at the root" of the SBOM. IIRC for CycloneDX that should be possible. For SPDX, that would mean some kind of "package relates to SPDX document" relationship, which doesn't exist. What it does today, is to return "all packages of an SBOM", which doesn't match the name Root and it's description.
However, I am not sure there is a way to actually find all "root level" packages. As there is no definition of a relationships to the root of the document, other than the "describes" relationship.
Maybe, the solution is to rename the enum variant? Or maybe the solution is to implement ::Root as "describes"?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Just to be clear, this is about "packages of an SBOM", not PURLs.
While working on some test cases, I noticed two odd things:
The first
The first issue seems easy. Packages are found by relationships, and if the same package is found multiple times through that, then this will translate into multiple packages.
As the information of e.g. the relationships type is dropped at some point, it's no longer clear that was the case:
trustify/modules/fundamental/src/sbom/service/sbom.rs
Line 399 in 1a2714a
Just filtering out those duplicate packages at a later time won't work, as that might have an impact on pagination. Right now, that's not a problem. So we could commit to doing just that.
Otherwise there needs to be a way to search for relationships (returning that info), vs search for packages (which doesn't).
The second
The second issue is a bit trickier.
The idea of the
SbomPackageReference::Root
was to target all packages which are "at the root" of the SBOM. IIRC for CycloneDX that should be possible. For SPDX, that would mean some kind of "package relates to SPDX document" relationship, which doesn't exist. What it does today, is to return "all packages of an SBOM", which doesn't match the nameRoot
and it's description.However, I am not sure there is a way to actually find all "root level" packages. As there is no definition of a relationships to the root of the document, other than the "describes" relationship.
Maybe, the solution is to rename the enum variant? Or maybe the solution is to implement
::Root
as "describes"?Beta Was this translation helpful? Give feedback.
All reactions