Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clarify use of "bomlink" in schema #217

Closed
jkowalleck opened this issue May 9, 2023 · 5 comments · Fixed by #236
Closed

clarify use of "bomlink" in schema #217

jkowalleck opened this issue May 9, 2023 · 5 comments · Fixed by #236
Labels

Comments

@jkowalleck
Copy link
Member

I am still uncertain which elements allow the use of bomlink.
From use cases it appears to be possible in externalReferences[].url, vulnerabilities[].affects[].ref.
Any where else?

I'd suggest enhancing the schema to make it visible where a bomlink is allowed and where it is not.
This helps tool builders, parsers, and most importantly clarifies this from schema, not only some additional pamphlets/texts.

@stevespringett
Copy link
Member

Related to #179

@stevespringett
Copy link
Member

vulnerabilities[].affects[].ref is just a string, not a URI, but external references are entirely possible (and recommended)

@jkowalleck
Copy link
Member Author

jkowalleck commented May 13, 2023

the thing is, we introduced an extra type alias "refType" for strings, to make it clear that some strings are not alike.

  • refType Identifier-DataType for interlinked elements.

in dependencies these the attribute ref are of "refType", in components the bom-ref is of "refType". the dependencies[].ref there is expected to have a counterpart in components[].bom-ref
no bomlink allowed.

the vulnerabilities[].affects[].ref is of "refType", and - AFAIK - allowed to reference a components[].bom-ref, or be a bomlink - which should have a certain format.
So, vulnerabilities[].affects[].ref value can have a counterpart in the current CDX document, nor in another CDX document if it is in the format of a bomlink. This is not clear from the schema,

i propose to introduce a new type "bomlink", a string -alias with a constraint: it must match the pattern
urn:cdx:[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}/[1-9][0-9*]#.+.

  1. "urn:cdx:" is hard
  2. pattern from serialnumber-uuid-part
  3. "/" is hard
  4. pattern for integer
  5. "#" is hard
  6. any non-empty string

This new type "bomlink" should be added wherever a "bomlink" is allowed/expected, so that digesting software authors are aware from reading the schema, that this special string at certain structures can have more meaning.
Otherwise, we would end up with lots of text describing specialties.

I might draft a pullrequest to show how this might look like.

@jkowalleck
Copy link
Member Author

jkowalleck commented May 26, 2023

@stevespringett wrote here: #229 (comment)

Every URL in CycloneDX can either be a URL or a BOM-Link.

@jkowalleck
Copy link
Member Author

Possibly caused #136

@CycloneDX CycloneDX locked and limited conversation to collaborators May 30, 2023
@jkowalleck jkowalleck converted this issue into discussion #232 May 30, 2023
@jkowalleck jkowalleck linked a pull request Jun 5, 2023 that will close this issue

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants