SPDX export: Epic and open questions

[stanislaw]

Tasks

• Basic integration test.
• Print basic Document, Package, File, Snippet.
• Print basic relationships.
• SHA256 for File
• SHA256 for Package
• SHA256 for Snippet
• Finding requirements-to-files relations and their files, recording them as SPDX files.
• Printing parent and child requirement relations as SNIPPETS connected with REQUIREMENT_FOR.
• Support MID- and UID-based identification.
• Data license: CC-0.
• Implement element and root_element.
• Implement Snippet's comment.
• Implement Snippet's description.
• Implement File's comment.
• Implement File's description. For an SDoc file description – number of requirements.
• SPDX formatting issues. spdx3: element_writer: switch from tab characters to two spaces spdx/tools-python#785.
• It looks like the Snippet implementation in SPDX 3 is not finished. spdx3: write_snippet: fix the presentation of line and byte ranges spdx/tools-python#786

## Snippet
SPDXID: SPDXRef-SNIPPET
line_range: PositiveIntegerRange(begin=12, end=15)

• SoftwarePurpose enum is missing a type for Requirement. The closest I found is DOCUMENTATION.
  Also, the serializer seems to ignore the software_purpose field, and it is not printed in the .spdx file. spdx3: software_purpose: add REQUIREMENT type spdx/tools-python#787.

• What is specVersion: 1.2.3? Is that SPDX version? Yes, 3.0.0 should be the version for now.

Open questions

• In an SPDX file, can we have more than one SPDX Document?

[G.O.] No – an SPDX document represents a unit of serialization (a file). Keeping one SPDX document to one file allows for validating external references to SPDX documents via hashing the file.

• In a SPDX document, can we have more than one SPDX Package? If there can be several Packages, which one takes the role of a "root element"?

[G.O.] Yes. You can also have multiple “root elements”. In terms of what you put as the root, it would depend on the use case. A typical scenario would be to have the packages in an SPDX collection and the collection would be the root element (an SBOM is a type of collection). It is also possible to have a flat SPDX document with all of the packages listed as root elements.

• When we are dealing with larger projects, is it typical that there is one master SPDX file that includes references to other files, or the collection of SPDX files is rather federated and the content from multiple files is simply concatenated horizontally without a single top-most entity? Here, I am thinking about the Zephyr's source files, licenses, documentation, requirements, and all sorts of other things. What would be the right way to structure the SPDX content into different files? One SPDX file for Zephyr or rather an assembly of SPDX files?

[G.O.] For large projects, I would recommend multiple files. There are two reasons to modularize the SPDX documents – size and the ability to add information at different points in the build / release / deploy process. An example of the latter is you could have a “source Bill of Materials” built when the files are compiled with the knowledge of what files are compiled into a binary and a separate “deploy Bill of Materials” the specifies the dynamic dependencies when the package is actually deployed with the knowledge of exactly which libraries are linked.

• SPDX 3 Python code seems to be missing a validation function.
• SPDX 3 Python code - YAML writer?
• How to verify a requirements package? SHA256 of a complete folder that is given to StrictDoc? Ignore non-sdoc files in that folder?

Attachments

1 (Creation Information)

2 (verified using)