Add support for OmniBOR and Software Heritage persistent IDs #414
Conversation
Signed-off-by: Steve Springett <[email protected]>
schema/bom-1.6.proto
Outdated
| @@ -148,6 +148,10 @@ message Component { | |||
| repeated OrganizationalContact authors = 29; | |||
| // Textual strings that aid in discovery, search, and retrieval of the associated object. Tags often serve as a way to group or categorize similar or related objects by various attributes. Examples include "json-parser", "object-persistence", "text-to-image", "translation", and "object-detection". | |||
| repeated string tags = 30; | |||
| // Specifies the OmniBOR Artifact ID. The OmniBOR, if specified, MUST be valid and conform to the specification defined at: https://www.iana.org/assignments/uri-schemes/prov/gitoid | |||
| optional string omnibor = 31; | |||
There was a problem hiding this comment.
If I understand correctly the same package url identified by a version or tag could have several gitoid which is based on git commit hashes.
There was a problem hiding this comment.
Can you reach out to the OmniBOR folks and confirm. If we need to make this an array, its an easy change.
There was a problem hiding this comment.
While a purl could have multiple OmniBORs, how about the specific component used? If I have a single component, with or without a purl, can a component have multiple gitoids? I didn't think this was possible as I thought a single artifact could only have a single gitoid.
There was a problem hiding this comment.
https://omnibor.io/glossary/omnibor/#omnibor-identifier
As per this doc, every class, .so or, source code would have its own ID. It is not clear if there is a single parent artifact id that can be used without listing the child id. Best to ask the omnibor team directly for some examples and clarifications
schema/bom-1.6.proto
Outdated
| // Specifies the OmniBOR Artifact ID. The OmniBOR, if specified, MUST be valid and conform to the specification defined at: https://www.iana.org/assignments/uri-schemes/prov/gitoid | ||
| optional string omnibor = 31; | ||
| // Specifies the Software Heritage persistent identifier (SWHID). The SWHID, if specified, MUST be valid and conform to the specification defined at: https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html | ||
| optional string swhid = 32; |
There was a problem hiding this comment.
Same purl could have several swhid since it is based on the repository that was used to archive. For example apache projects could be mirrored in several git servers. Each of these would have same purls but different swhid.
| "cpe": "cpe:2.3:a:example:acme-library:1.0.0:*:*:*:*:*:*:*", | ||
| "purl": "pkg:maven/com.example/[email protected]", | ||
| "omnibor": "gitoid:blob:sha1:261eeb9e9f8b2b4b0d119366dda99c6fd7d35c64", | ||
| "swhid": "swh:1:cnt:94a9ed024d3859793618152ea559a168bbcbb5e2" |
There was a problem hiding this comment.
I think we need to update docs to list the procedure involved in figuring out the swhid and omnibor id.
There was a problem hiding this comment.
Omnibor is a system, a collection of things and processes and such , and the OmniBOR ID is the actual identifier string - according to https://omnibor.io/glossary/omnibor/#omnibor-identifier
Therefore, change it from naming the field for the identifier omnibor, but use something like omnibor-id or something
stevespringett
added
promote to tc54
Signed-off-by: Steve Springett <[email protected]>
Signed-off-by: Steve Springett <[email protected]>
| "omnibor": "gitoid:blob:sha1:261eeb9e9f8b2b4b0d119366dda99c6fd7d35c64", | ||
| "swhid": "swh:1:cnt:94a9ed024d3859793618152ea559a168bbcbb5e2" | ||
| "omnibor": [ | ||
| "gitoid:blob:sha1:261eeb9e9f8b2b4b0d119366dda99c6fd7d35c64", |
There was a problem hiding this comment.
Thank you. I think to make the omnibor information complete the Artifact Dependency Graph must be represented in dependencies section using provides.
## Added * Core enhancement: Attestation ([#192](#192) via [#348](#348)) * Core enhancement: Cryptography Bill of Materials — CBOM ([#171](#171), [#291](#291) via [#347](#347)) * Feature to express the URL to source distribution ([#98](#98) via [#269](#269)) * Feature to express the URL to RFC 9116 compliant documents ([#380](#380) via [#381](#381)) * Feature to express tags/keywords for services and components (via [#383](#383)) * Feature to express details for component authors ([#335](#335) via [#379](#379)) * Feature to express details for component and BOM manufacturer ([#346](#346) via [#379](#379)) * Feature to express communicate concluded values from observed evidences ([#411](#411) via [#412](#412)) * Features to express license acknowledgement ([#407](#407) via [#408](#408)) * Feature to express environmental consideration information for model cards ([#396](#396) via [#395](#395)) * Feature to express the address of organizational entities (via [#395](#395)) * Feature to express additional component identifiers: Universal Bill Of Receipts Identifier and Software Heritage persistent IDs ([#413](#413) via [#414](#414)) ## Fixed * Allow multiple evidence identities by XML/JSON schema ([#272](#272) via [#359](#359)) This was already correct via ProtoBuff schema. * Prevent empty `license` entities by XML schema ([#288](#288) via [#292](#292)) This was already correct in JSON/ProtoBuff schema. * Prevent empty or malformed `property` entities by JSON schema ([#371](#371) via [#375](#375)) This was already correct in XML/ProtoBuff schema. * Allow multiple `licenses` in `Metadata` by ProtoBuff schema ([#264](#264) via [#401](#401)) This was already correct in XML/JSON schema. ## Changed * Allow arbitrary `$schema` values by JSON schema ([#402](#402) via [#403](#403)) * Increased max length of `versionRange` (via [`3e01ce6`](3e01ce6)) * Harmonized length of `version` (via [#417](#417)) ## Deprecated * Data model "Component"'s field `author` was deprecated. (via [#379](#379)) Use field `authors` or field `manufacturer` instead. * Data model "Metadata"'s field `manufacture` was deprecated. ([#346](#346) via [#379](#379)) Use "Metadata"'s field `component`'s field `manufacturer` instead. - for XML: `/bom/metadata/component/manufacturer` - for JSON: `$.metadata.component.manufacturer` - for ProtoBuf: `Bom:metadata.component.manufacturer` ## Documentation * Centralize version and version-range (via [#322](#322)) * Streamlined SPDX expression related descriptions (via [#327](#327)) * Enhanced descriptions of `bom-ref`/`refType` ([#336](#336) via [#344](#344)) * Enhanced readability of enum documentation in JSON schema ([#361](#361) via [#362](#362)) * Fixed typo "compliment" -> "complement" (via [#369](#369)) * Added documentation for enum "ComponentScope"'s values in JSON schema ([#293](#293) via [`d92e58e`](d92e58e)) Texts were a taken from the existing ones in XML/ProtoBuff schema. * Added documentation for enum "TaskType"'s values ([#245](#245) via [#377](#377)) * Improve documentation for data model "Metadata"'s field `licenses` ([#273](#273) via [#378](#378)) * Added documentation for enum "MachineLearningApproachType"'s values ([#351](#351) via [#416](#416)) * Rephrased some texts here and there. ## Test data * Added test data for newly added use cases * Added quality assurance for our ProtoBuf schemas ([#384](#384) via [#385](#385))
Closes #413