feat: add custom properties to external references #610
Conversation
Urist-McGit
force-pushed
the
feat/ext-reference-properties
branch
2 times, most recently
from
f5e6bed to
aaf9399
Compare
With this property external references can be annotated with additional metadata in a machine-readable format. Signed-off-by: Christoph Steiger <[email protected]>
Urist-McGit
force-pushed
the
feat/ext-reference-properties
branch
from
aaf9399 to
ed9918d
Compare
|
@Urist-McGit, the current state looks promising. According to the CycloneDX working model, the next step would be to move from "prototype" to "draft", meaning the community review phase (RFC) would start. |
|
@gernot-h any reservations? Otherwise I think we can continue to the RFC |
|
Thanks, @Urist-McGit, for taking care! From my side, please proceed to RFC step! |
jkowalleck
added
draft
RFC notice sent
|
RFC notice sent.
Public RFC period ends April 13, 2025 |
| <reference type="component-analysis-report"> | ||
| <url>http://example.com/extref/component-analysis-report</url> | ||
| <properties> | ||
| <property name="author">John Doe</property> |
There was a problem hiding this comment.
This is confusing to me. What if the external source has a different value for author and timestamp?
There was a problem hiding this comment.
Sorry, but what exactly do you mean by "different values for author and timestamp"? This is an example for additional properties provided in the SBOM for this report. They might be added because this metadata isn't available from the external source or just because it saves us an additional query to the external server when I need this information when handling the SBOM.
There was a problem hiding this comment.
Take externalReferences.type == bom. If there are differences in the value for properties (say author), then there is a question about source of truth. Caller has to make an additional query to the external server.
We use annotations attribute to add/store additional information about certain attributes. Any issues with that?
There was a problem hiding this comment.
Hmm, but how would how such additional information for an external reference differ from any other data points you provide for a component in your SBOM? Same problem would also apply for author or licenses or other properties of a component and most of them could usually also be looked up on a homepage or package repository. I think the idea of an SBOM is to document your understanding of your BOM in a central place, no-one protects you from providing wrong data there.
Regarding annotations: What we need is a machine-readable key/value store per external reference. Today, we mis-use the comment field of external references for storing such data, which obviously doesn't scale. I don't think using annotations would really improve that and also doesn't allow us to document these fields in our taxonomy.
|
this one just was accepted during a Ecma TC54 meeting 👍 |
## Fixed * XML schema: add type for `ComponentData` sub-elements ([#600] via [#601]) * JSON schema: added the correct `deprecated` mark for already deprecated structures (via [a973a6b]) ## Deprecated * Deprecated various fields and structures related to _cryptographic transparency_ - _CBOM_ . (via [#657]) Use the newly added structures and fields for detailing the information instead. ## Changed * Extended the scope of _formulations_. (via [#647]) From now on, _formulations_ may be used to describe how any referencable object within the BOM came together, including components, services, metadata, declarations, or the BOM itself. Before, it was restricted to components and services. ## Added * Support for _external components_ with _version-ranges_ ([#321] via [#586]) * Support for _multiple_ SPDX License Expressions alongside with other licenses ([#454] via [#582]) * Support for _Streebog hashing algorithm_ ([#485] via [#525]) * Support for license expression _details and properties_ ([#549], [#554] via [#599]) * Support for expressing BOM distribution constraints with the _Traffic Light Protocol_ (TLP) in metadata ([#595] via [#604], [#653]) * Support for representing _patent information_ ([#596] via [#597]) * Support for _properties_ on external-references ([#608] via [#610]) * Support for _citations_ ([#630] via [#629]) * Support for detailing _cryptographic transparency_ information - _CBOM_ ([#569] via [#657]) ## Documentation * Elaborated component classification "platform", explicitly expressed that it includes just-in-time compilers and interpreters ([#233] via [#647]) * Removed the term "optional" from the schema where the definition was already unambiguous ([#616], [#649] via [#680]) ## Test data * Add test data for CycloneDX 1.7 implementations in XML, JSON, Protobuf [#233]: #233 [#321]: #321 [#454]: #454 [#485]: #485 [#525]: #525 [#549]: #549 [#554]: #554 [#569]: #569 [#582]: #582 [#586]: #586 [#595]: #595 [#596]: #596 [#597]: #597 [#599]: #599 [#600]: #600 [#601]: #601 [#604]: #604 [#608]: #608 [#610]: #610 [#616]: #616 [#629]: #629 [#630]: #630 [#647]: #647 [#649]: #649 [#653]: #653 [#657]: #657 [#680]: #680 [a973a6b]: a973a6b ---- - fixes #233 - fixes #321 - fixes #454 - fixes #485 - fixes #549 - fixes #554 - fixes #595 - fixes #596 - fixes #600 - fixes #608 - fixes #629 - fixes #616 - fixes #649
4 participants
With this property external references can be annotated with additional metadata in a machine-readable format.
As discussed in #608 this adds support for custom properties in external references.
fixes #608