Add SPDX format support for SBOM #608

midnightercz · 2024-08-22T11:26:14Z

Support for SPDX format was added to fetch-depds command and also to merge_syft_sboms.
No changes were made in particular package manager generating components which are then converted to cyclonedx format. SPDX sbom can be obtained by calling Sbom.to_spdx().
New switch sbom-type was added to merge_syfy_sboms, so user can choose which output format should be generated - default is cyclonedx. Once all tooling is ready to consume spdx sboms, cutoff changes in this repository can be started.

Maintainers will complete the following section

Commit messages are descriptive enough
Code coverage from testing does not decrease and new code is covered
Docs updated (if applicable)
Docs links in the code are still valid (if docs were updated)

Note: if the contribution is external (not from an organization member), the CI
pipeline will not run automatically. After verifying that the CI is safe to run:

approve GitHub Actions workflows by clicking a button
approve the Red Hat Trusted App Pipeline container build by commenting /ok-to-test
(as is the standard for Pipelines as Code)

brunoapimentel · 2024-08-22T13:10:41Z

Just a quick heads-up: the utils/merge_syft_sbom.py script was removed from this repo and now lives here. So you'll need to propose the related changes there instead.

cachi2/core/models/validators.py

midnightercz · 2024-08-22T13:56:26Z

Just a quick heads-up: the utils/merge_syft_sbom.py script was removed from this repo and now lives here. So you'll need to propose the related changes there instead.

I thought I will eventually integrate the changes into new subcommand implemented here: #593 but it wasn't merged yet when I started working on this one

tests/unit/models/test_sbom.py

cachi2/core/models/sbom.py

chmeliik · 2024-08-27T08:36:07Z

cachi2/core/models/sbom.py

+                SPDXPackage(
+                    name=component.name,
+                    version=component.version,
+                    package_download_location=component.purl,


What will replace component.properties? Those carry crucial information. Enterprise Contract inspects them and, for example, blocks builds if the SBOM has any cachi2:pip:package:binary properties

I don't think there's anything equivalent for spdx package. See https://spdx.github.io/spdx-spec/v2.3/package-information/. Syft convert discards this information. I'll check with EC devs how to approach this

A solution could be to keep using CycloneDX in cachi2 and not even add SPDX support. If a lossy conversion is all that Konflux needs, the build pipeline can use syft convert for that

Or the release pipeline can do that. TBH I fail to see why builds would have to publish SPDX already. Is there a design doc for this?

cachi2/core/models/sbom.py

MartinBasti · 2024-08-27T10:54:31Z

cachi2/core/models/sbom.py

+            key=lambda ref: (ref.referenceLocator, ref.referenceType, ref.referenceCategory),
+        )
+
+    return sorted(list(unique_items.values()), key=lambda item: (item.name, item.version))


also here, list() is not needed

MartinBasti · 2024-08-27T12:41:20Z

cachi2/core/models/sbom.py

+                SPDXPackage(
+                    name=component.name,
+                    version=component.version,
+                    package_download_location=component.purl,


Where is this parameter defined? package_download_location

I think that this function needs separate and better unittest, if expected SBOM is really good one, current test testing this is shady as it basically just tests if f()==f() with few extra steps

cachi2/core/models/sbom.py

MartinBasti · 2024-08-27T14:59:33Z

typo in commit message and PR: s/SDPX/SPDX/

cachi2/core/models/sbom.py

midnightercz · 2024-08-30T07:37:32Z

Thanks for all the reviews and comments. I also wanted to add spdx support into merge-sboms subcommand but I noticed that in the tests you don't really test merged output. Or am I missing something?

cachi2/core/models/sbom.py

a-ovchinnikov

Mostly LGTM, a couple of minor changes is needed. Edit: you would also need to make sure UTs pass.

cachi2/core/models/sbom.py

tests/unit/test_cli.py

a-ovchinnikov · 2024-09-09T19:29:08Z

Thanks for all the reviews and comments. I also wanted to add spdx support into merge-sboms subcommand but I noticed that in the tests you don't really test merged output. Or am I missing something?

merge-sboms is a thin wrapper around an internal function that is tested elsewhere. It does not do much except some validation of input and then invoking a method for saving merge results (which is also tested elsewhere). There is not much value in doing this sort of test.

midnightercz · 2024-10-07T07:51:38Z

I believe we can improve the way CycloneDX's properties are being translated to SPDX. For example:
{
  "name":  "cachi2:found_by", 
  "value": "cachi2"
}
Could be turned into:
{
  "annotator": "cachi2",
  "annotationDate": "2024-10-01T11:03:40.799221",
  "annotationType": "OTHER",
  "comment": "found_by:cachi2"
}
My reasoning is that the annotator field already states that Cachi2 is the author of that annotation, so we can drop the prefix cachi2:, which serves the same purpose. Then, we could just append the value in the end of the string, instead of having the inline JSON, which is arguably harder to read.

If folks like the idea, this can be done as a follow up, no need to block this PR because of this.

I get your idea, but what if you decide to use new properties? (Our) Tooling reading SPDX annotations could depend on rule if annotator is cachi2 then comment is string in json format. Then if you add property {"name": "foo", "value": "bar"}, with your proposal it would turn into {"annotator": "bar", "comment": "foo"}. I think approach to dump whole property in json is more universal

brunoapimentel · 2024-10-07T13:14:41Z

I get your idea, but what if you decide to use new properties? (Our) Tooling reading SPDX annotations could depend on rule if annotator is cachi2 then comment is string in json format. Then if you add property {"name": "foo", "value": "bar"}, with your proposal it would turn into {"annotator": "bar", "comment": "foo"}. I think approach to dump whole property in json is more universal

To clarify, my proposal is to omit the prefix we add to every Cachi2-generated property, since the annotator is already Cachi2. So it's not the value that becomes the annotator, as you mentioned above. The second part of the proposal is to remove the json formatting, since it does not add anything to the info.

{
    "name": "prefix:property"
    "value":  "content"
}

{
    "annotator": "prefix"
    "comment":  "property:content"
}

This should only apply to Cachi2-generated propertis, though. It is all we deal with for now.

brunoapimentel · 2024-10-07T15:30:32Z

cachi2/interface/cli.py

+        # Remove extra fields which are not in Sbom or SPDXSbom models
+        # Both SBom and SPDXSBom models are only subset of cyclonedx and SPDX specifications
+        # Therefore we need to make sure only fields accepted by the models are present


Do we need to perform this cleanup? I get that our models are only a subset of the full spec, but since this function is limited to support only Cachi2-produced SBOMs, I believe we could skip this sanitization here. Any SBOM that contains extra fields was not produced by Cachi2, and we don't need to handle them, we can just fail the request.

Removing this santitization will make the unit test that uses a Syft SBOM fail... but I think that is the expected behavior, so we need to fix that test.

FAILED tests/unit/test_cli.py::TestMergeSboms::test_a_user_can_successfully_save_sboms_merge_results_to_a_file_in_spdx_format[sbom_files_to_merge0] - AssertionError: Error: UnexpectedFormat: /home/bpimente/Projects/cachi2/tests/unit/data/sboms/syft.bom.spdx.json does not appear to be a valid Cachi2 SBOM. Please check if the format of your file is correct. If yes, please let the maintainers know that Cachi2 doesn't handle it properly.

brunoapimentel · 2024-10-07T16:05:08Z

cachi2/interface/cli.py

        sbom: Union[Sbom, SPDXSbom] = Sbom(
            components=merge_component_properties(
-                chain.from_iterable(cast(Sbom, s).components for s in sboms_to_merge)
+                chain.from_iterable(cast(Sbom, s).components for s in cyclonedx_sboms_to_merge)


Why do we need to use cast here? mypy seems to be fine without it. (same applies to the other uses of cast in this function)

brunoapimentel · 2024-10-07T16:09:13Z

cachi2/core/models/sbom.py

+                if ref.referenceType == "purl":
+                    purls.append(ref.referenceLocator)
+
+            # cyclonedx doens't support multiple purls, therefore


typo: doens't

lcarva · 2024-10-07T17:34:36Z

cachi2/core/models/sbom.py

+                        annotator="cachi2",
+                        annotationDate=datetime.datetime.now().isoformat(),
+                        annotationType="OTHER",
+                        comment=json.dumps({"name": f"{prop.name}", "value": f"{prop.value}"}),


Is the purpose of the comment to be informative?

I need to list packages found by cachi2, and I'm wondering if this enough:

annotation.annotator == "cachi2" annotation.annotationType == "OTHER"

Or do I also need to parse the comment?

Maybe @brunoapimentel or @chmeliik know?

AFAIK the comments are the replacement for CycloneDX properties

cachi2/cachi2/core/models/sbom.py

Lines 7 to 13 in b289c91

PropertyName = Literal[

"cachi2:found_by",

"cachi2:missing_hash:in_file",

"cachi2:pip:package:binary",

"cdx:npm:package:bundled",

"cdx:npm:package:development",

]

But if you just need to list the packages found by cachi2, annotation.annotator == "cachi2" should be enough

ack. Thank you!

I don't want to speak behalf of cachi2 developers. I would say yes. But I wouldn't recommend it. With that approach you would simply rely on internal implementation detail which I believe isn't going to be guaranteed to be preserved in the future

Good point. For found_by, that's probably ok, but when we get to other properties, we'll very much need to know more details. If comment is the only attribute available to stuff that information, then we'll need that to be stable.

I'd say that annotation.annotator will always be cachi2, since all the properties are inserted by Cachi2. This is also true for standard CycloneDX properties (such as cdx:npm:package:bundled).

In the context of Konflux, there will be annotations inserted by other tools in the final SBOM, but I'd say you can count on the annotator field to pick those out.

a-ovchinnikov

Mostly LGTM, some optional nitpicks, but I have a couple of small yet blocking questions on the new code. Also could you please squash those commits which revert changes in the earlier commits from the same PR?

a-ovchinnikov · 2024-10-07T18:21:07Z

cachi2/core/models/sbom.py

+                    )
+                )
+            # if there's no purl and no package name or version, it's just wrapping element for
+            # spdx package which is layer bellow SPDXDocument in relationships


s/layer bellow/one layer below/

a-ovchinnikov · 2024-10-07T18:25:15Z

cachi2/core/models/sbom.py

+                )
+            # if there's no purl and no package name or version, it's just wrapping element for
+            # spdx package which is layer bellow SPDXDocument in relationships
+            if not purls and not package.name and not package.versionInfo:


Non-blocking opinionated nitpick: not any((purls, package.name, package.versionInfo)) reads slightly better.

cachi2/core/models/sbom.py

a-ovchinnikov · 2024-10-07T18:41:25Z

cachi2/core/models/sbom.py

+        """Convert a SPDX SBOM to a CycloneDX SBOM."""
+        components = []
+        for package in self.packages:
+            properties = []


I strongly recommend going declarative on both properties and purls:

properties = [Property(**json.loads(an.comment)) for an in package.annotations] purls = [ref.referenceLocator for ref in package.externalRefs if referenceType == "purl"]

Will not block on this one, but it does make code tidier.

a-ovchinnikov · 2024-10-07T18:52:24Z

cachi2/interface/cli.py

+        cyclonedx_sboms_to_merge = []
+        for _sbom in sboms_to_merge:
+            if not isinstance(_sbom, Sbom):
+                cyclonedx_sboms_to_merge.append(_sbom.to_cyclonedx())


Are we sure we want to merge SBOMs in different formats? If yes then wouldn't it make sense to declaratively and unconditionally convert them to same format first, then merge, then convert the result to the expected output format? Something like this:

sboms_to_merge = [sbom.to_cyclonedx() for sbom in sboms_to_merge] resulting_sbom = Sbom(components=merge_component_properties(...), ...) if sbom_type == SBOMFormat.spdx: resulting_sbom = resulting_sbom.convert_to_spdx()

Edit: spelling

I was thinking about this and I'm not sure if that good idea regarding to multiarch sboms. I haven't seen one yet, but I assume it will contain hierarchy like: root -> virtual-arch-package -> [ arch packages, ... ]. That would be lost if converted to spdx, so I think we should avoid any conversion if it's not necessary

FWIW, Cachi2 does not produce multiarch SBOMs, so we don't need to support merging those. We can update the merging script once that changes, but I don't see it happening in the near future.

a-ovchinnikov · 2024-10-07T18:54:20Z

tests/unit/models/test_sbom.py

@@ -462,6 +464,34 @@ def test_to_spdx(self, isodate: datetime.datetime) -> None:
            ),
        ]

+    def test_to_cyclonedx_around(self, isodate: datetime.datetime) -> None:


This name is rather cryptic. What do you think about
test_spdx_sbom_can_be_converted_to_cyclonedx_and_back_without_loosing_any_data?
The same question applies to all _around tests in this PR.

a-ovchinnikov · 2024-10-07T18:57:03Z

tox.ini

@@ -13,7 +13,7 @@ usedevelop = true
 deps =
    -rrequirements-extras.txt
 commands =
-    pytest \
+    pytest -vv \


Is this change related to the PR?

midnightercz · 2024-10-08T17:13:09Z

I get your idea, but what if you decide to use new properties? (Our) Tooling reading SPDX annotations could depend on rule if annotator is cachi2 then comment is string in json format. Then if you add property {"name": "foo", "value": "bar"}, with your proposal it would turn into {"annotator": "bar", "comment": "foo"}. I think approach to dump whole property in json is more universal

To clarify, my proposal is to omit the prefix we add to every Cachi2-generated property, since the annotator is already Cachi2. So it's not the value that becomes the annotator, as you mentioned above. The second part of the proposal is to remove the json formatting, since it does not add anything to the info.
{
    "name": "prefix:property"
    "value":  "content"
}
{
    "annotator": "prefix"
    "comment":  "property:content"
}
This should only apply to Cachi2-generated propertis, though. It is all we deal with for now.

There's property
Property(name="cachi2:missing_hash:in_file", value=str(lockfile_path)) in rpm module. How should that then be translated to annotation?

brunoapimentel · 2024-10-09T01:34:55Z

There's property Property(name="cachi2:missing_hash:in_file", value=str(lockfile_path)) in rpm module. How should that then be translated to annotation?

My initial thought was:

{
    "annotator": "cachi2"
    "comment":  "missing_hash:in_file:./path/to/the/file"
}

But seeing the other thread you're keeping with Lui made me realize that Cachi2 adds standard CycloneDx properties (such as cdx:npm:package:bundled). So, cachi2: was actually a way to namespace our own custom properties, and I believe it should be kept.

I still don't quite like the inline JSON, and also that it has name and value that are part of the CycloneDX spec (it could be simplified to {"cachi2:missing_hash:in_file": "/path/to/the/file"}). I'll open a discussion about this later, as I said, I don't want this to block this PR.

I also saw that SPDX 3.0 adds a ContentType field to annotations, which we could leverage to state that it contains JSON when we move to the new version.

midnightercz · 2024-10-09T13:24:13Z

I still don't quite like the inline JSON

I agree, but on the other hand, json dumps will handle any escaping, so as property name and value you can have anything which is compatible with cyclonedx property

a-ovchinnikov

It looks like the scope of this PR keeps growing. It might make sense splitting it into several PRs.

a-ovchinnikov · 2024-10-11T15:48:33Z

cachi2/interface/cli.py

+) -> List[SPDXRelation]:
+    """Merge SPDX relationships.
+
+    Function takes two relationsships lists and unified list of packages.


s/relationsships/relationships/

a-ovchinnikov · 2024-10-11T15:49:17Z

cachi2/interface/cli.py

+    """Merge SPDX relationships.
+
+    Function takes two relationsships lists and unified list of packages.
+    For relationhips lists, map and inverse map of relations is created. SPDX document usually


s/relationhips/relationships/
s/is/are/

a-ovchinnikov · 2024-10-11T18:06:39Z

cachi2/interface/cli.py

+    Function takes two relationsships lists and unified list of packages.
+    For relationhips lists, map and inverse map of relations is created. SPDX document usually
+    contains virtual package which serves as "envelope" for all real packages. These virtual
+    packages are search in the relationsships and thier ID is stored as middle element.


s/are search/are searched/
s/relationsships/relationships/
s/thier/their/

a-ovchinnikov · 2024-10-11T20:46:55Z

cachi2/interface/cli.py

@@ -405,6 +405,94 @@ def all_files_are_jsons(sbom_files_to_merge: Paths) -> Paths:
    return all_files_are_jsons(enough_files_for_merge(list(set(sbom_files_to_merge))))


+def merge_relationships(


Two observations: first, this is not a part of CLI and second, the logic is quite complex, but there are no tests to ensure that it is done correctly. I think this function should be moved, split into high-level and low-level parts and covered with tests.

where would you move it?

a-ovchinnikov · 2024-10-11T20:52:30Z

cachi2/interface/cli.py

+    root_ids = []
+    maps = []
+    inv_maps = []
+    middles = []


I wonder if envelop_packages_ids would be better in conveying what this variable refers to? I found myself going back to the docstring several times to refresh what 'middle' and 'middles' mean.

Yeah, I can rename it.

a-ovchinnikov · 2024-10-11T20:56:15Z

cachi2/interface/cli.py

@@ -405,6 +405,94 @@ def all_files_are_jsons(sbom_files_to_merge: Paths) -> Paths:
    return all_files_are_jsons(enough_files_for_merge(list(set(sbom_files_to_merge))))


+def merge_relationships(
+    relationships_list: List[List[SPDXRelation]], doc_ids: List[str], packages: List[SPDXPackage]


A list is a sequence of variable length, the docstring states that the function takes two relationship lists. If it is just two then it would make more sense to have 'this' and 'that' r_lists and to merge them. Or some better name which would let everyone see that there are two distinct entities to be processed. 'main' and 'other' are good candidates given that those are already used in the code.

If it is not about merging two lists then I strongly recommend making it about merging two lists and then reducing any list of lists with it if needed.

Originally I created the method for two lists but I realized cachi2 actually can take multiple files.

If it is not about merging two lists then I strongly recommend making it about merging two lists and then reducing any list of lists with it if needed.

But that would mean another merge method call. I think merging all together is more efficient and calling merge(A,B) in cascade.

midnightercz · 2024-10-14T08:41:08Z

It looks like the scope of this PR keeps growing. It might make sense splitting it into several PRs.

This is the last change. It won't grow more

Support for SPDX format was added to fetch-depds command and also to merge_syft_sboms. No changes were made in particular package manager generating components which are then converted to cyclonedx format. SPDX sbom can be obtained by calling Sbom.to_spdx(). New switch sbom-type was added to merge_syfy_sboms, so user can choose which output format should be generated - default is cyclonedx. Once all tooling is ready to consume spdx sboms, cutoff changes in this repository can be started. Signed-off-by: Jindrich Luza <[email protected]>

…file_spdx - package hash calculation helper - better sbom_name attribute description Signed-off-by: Jindrich Luza <[email protected]>

SPDXRef-DocumentRoot-File- includes all spdx packages and is set to be described by SPDXRef-DOCUMENT. This way of spdx generation is closer to way syft generates spdx Signed-off-by: Jindrich Luza <[email protected]>

Signed-off-by: Jindrich Luza <[email protected]>

- minor refactoring - renamed tests - fixed typos Signed-off-by: Jindrich Luza <[email protected]>

Signed-off-by: Jindrich Luza <[email protected]>

- Packages with no versions are deduplicated Signed-off-by: Jindrich Luza <[email protected]>

Signed-off-by: Jindrich Luza <[email protected]>

- renamed middles to envelopes Signed-off-by: Jindrich Luza <[email protected]>

Signed-off-by: Jindrich Luza <[email protected]>

- improved spdx merge tests Signed-off-by: Jindrich Luza <[email protected]>

MartinBasti reviewed Aug 22, 2024

View reviewed changes

cachi2/core/models/validators.py Outdated Show resolved Hide resolved

MartinBasti reviewed Aug 22, 2024

View reviewed changes

cachi2/core/models/validators.py Outdated Show resolved Hide resolved

midnightercz force-pushed the spdx-support branch from 5e78923 to e64cec4 Compare August 26, 2024 09:16

midnightercz requested a review from MartinBasti August 26, 2024 10:14

midnightercz force-pushed the spdx-support branch from e64cec4 to 4a10a9d Compare August 26, 2024 10:26

MartinBasti reviewed Aug 26, 2024

View reviewed changes

tests/unit/models/test_sbom.py Outdated Show resolved Hide resolved

a-ovchinnikov reviewed Aug 26, 2024

View reviewed changes

chmeliik reviewed Aug 27, 2024

View reviewed changes

eskultety changed the title ~~[STONEBLD-2714] Added SDPX format support for SBOM~~ Add SDPX format support for SBOM Aug 27, 2024

MartinBasti reviewed Aug 27, 2024

View reviewed changes

cachi2/core/models/sbom.py Outdated Show resolved Hide resolved

MartinBasti reviewed Aug 27, 2024

View reviewed changes

cachi2/core/models/sbom.py Outdated Show resolved Hide resolved

a-ovchinnikov reviewed Aug 27, 2024

View reviewed changes

midnightercz force-pushed the spdx-support branch from e08cfd6 to 0f308c0 Compare August 29, 2024 07:06

midnightercz requested review from chmeliik, MartinBasti and a-ovchinnikov August 29, 2024 07:19

midnightercz changed the title ~~Add SDPX format support for SBOM~~ Add SPDX format support for SBOM Aug 29, 2024

a-ovchinnikov reviewed Aug 29, 2024

View reviewed changes

cachi2/core/models/sbom.py Outdated Show resolved Hide resolved

cachi2/core/models/sbom.py Show resolved Hide resolved

cachi2/core/models/sbom.py Show resolved Hide resolved

cachi2/core/models/sbom.py Outdated Show resolved Hide resolved

midnightercz requested a review from a-ovchinnikov September 2, 2024 10:25

a-ovchinnikov reviewed Sep 4, 2024

View reviewed changes

cachi2/core/models/sbom.py Outdated Show resolved Hide resolved

cachi2/core/models/sbom.py Outdated Show resolved Hide resolved

cachi2/core/models/sbom.py Outdated Show resolved Hide resolved

cachi2/core/models/sbom.py Outdated Show resolved Hide resolved

midnightercz requested a review from a-ovchinnikov September 6, 2024 13:21

a-ovchinnikov reviewed Sep 9, 2024

View reviewed changes

cachi2/core/models/sbom.py Outdated Show resolved Hide resolved

tests/unit/test_cli.py Show resolved Hide resolved

tests/unit/test_cli.py Outdated Show resolved Hide resolved

a-ovchinnikov reviewed Sep 9, 2024

View reviewed changes

tests/unit/test_cli.py Outdated Show resolved Hide resolved

midnightercz force-pushed the spdx-support branch from 24872b7 to 98d68df Compare October 3, 2024 13:41

midnightercz requested review from a-ovchinnikov and brunoapimentel October 7, 2024 07:52

brunoapimentel reviewed Oct 7, 2024

View reviewed changes

lcarva reviewed Oct 7, 2024

View reviewed changes

a-ovchinnikov reviewed Oct 7, 2024

View reviewed changes

midnightercz force-pushed the spdx-support branch from 717769b to be48ebb Compare October 9, 2024 07:50

a-ovchinnikov reviewed Oct 11, 2024

View reviewed changes

midnightercz added 9 commits October 14, 2024 11:43

- Renamed test_a_user_can_successfully_save_sboms_merge_results_to_a_…

2b8efb4

…file_spdx - package hash calculation helper - better sbom_name attribute description Signed-off-by: Jindrich Luza <[email protected]>

Added SPDXRef-DocumentRoot-File-

b7b8b4a

SPDXRef-DocumentRoot-File- includes all spdx packages and is set to be described by SPDXRef-DOCUMENT. This way of spdx generation is closer to way syft generates spdx Signed-off-by: Jindrich Luza <[email protected]>

Support only PACKAGE-MANAGER with purl type as external reference

62058d7

Signed-off-by: Jindrich Luza <[email protected]>

Added support for merging cyclonedx with spdx

ab3d297

Signed-off-by: Jindrich Luza <[email protected]>

- Removed unsupported attributes strip

5d07297

- minor refactoring - renamed tests - fixed typos Signed-off-by: Jindrich Luza <[email protected]>

fixed tox.ini

35a288d

Signed-off-by: Jindrich Luza <[email protected]>

- Added code for merging relationships

2ef3507

- Packages with no versions are deduplicated Signed-off-by: Jindrich Luza <[email protected]>

Added test_merge_spdx

0db041f

Signed-off-by: Jindrich Luza <[email protected]>

midnightercz force-pushed the spdx-support branch from a2606bc to 28fc1a7 Compare October 14, 2024 09:43

midnightercz added 2 commits October 14, 2024 14:43

- Fixed doc strings

bf3331c

- renamed middles to envelopes Signed-off-by: Jindrich Luza <[email protected]>

Removed extra attr

4f1cb8c

Signed-off-by: Jindrich Luza <[email protected]>

midnightercz force-pushed the spdx-support branch from 28fc1a7 to 4f1cb8c Compare October 14, 2024 12:44

- Added missing envelope relation

84f95aa

- improved spdx merge tests Signed-off-by: Jindrich Luza <[email protected]>

	PropertyName = Literal[
	"cachi2:found_by",
	"cachi2:missing_hash:in_file",
	"cachi2:pip:package:binary",
	"cdx:npm:package:bundled",
	"cdx:npm:package:development",
	]

		@@ -405,6 +405,94 @@ def all_files_are_jsons(sbom_files_to_merge: Paths) -> Paths:
		return all_files_are_jsons(enough_files_for_merge(list(set(sbom_files_to_merge))))


		def merge_relationships(

Add SPDX format support for SBOM #608

Are you sure you want to change the base?

Add SPDX format support for SBOM #608

Conversation

midnightercz commented Aug 22, 2024

Maintainers will complete the following section

brunoapimentel commented Aug 22, 2024

midnightercz commented Aug 22, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MartinBasti Aug 27, 2024 • edited Loading

Choose a reason for hiding this comment

MartinBasti commented Aug 27, 2024

midnightercz commented Aug 30, 2024

a-ovchinnikov left a comment • edited Loading

Choose a reason for hiding this comment

a-ovchinnikov commented Sep 9, 2024

midnightercz commented Oct 7, 2024

brunoapimentel commented Oct 7, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

a-ovchinnikov left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

a-ovchinnikov Oct 7, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

midnightercz commented Oct 8, 2024

brunoapimentel commented Oct 9, 2024

midnightercz commented Oct 9, 2024

a-ovchinnikov left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

midnightercz Oct 14, 2024 • edited Loading

Choose a reason for hiding this comment

midnightercz commented Oct 14, 2024

MartinBasti Aug 27, 2024 •

edited

Loading

a-ovchinnikov left a comment •

edited

Loading

brunoapimentel commented Oct 7, 2024 •

edited

Loading

a-ovchinnikov Oct 7, 2024 •

edited

Loading

midnightercz Oct 14, 2024 •

edited

Loading