Initial steps to enhance the presentation of the CSAF model#1221
Initial steps to enhance the presentation of the CSAF model#1221sthagen merged 46 commits intoeditor-revision-2026-02-25from
Conversation
Signed-off-by: Stefan Hagen <stefan@hagen.link>
…of items (WIP) Signed-off-by: Stefan Hagen <stefan@hagen.link>
Signed-off-by: Stefan Hagen <stefan@hagen.link>
…and fxed a bug Signed-off-by: Stefan Hagen <stefan@hagen.link>
Signed-off-by: Stefan Hagen <stefan@hagen.link>
Signed-off-by: Stefan Hagen <stefan@hagen.link>
Signed-off-by: Stefan Hagen <stefan@hagen.link>
csaf_2.1/prose/edit/src/schema-elements-02-props-04-vulnerabilities.md
Outdated
Show resolved
Hide resolved
Signed-off-by: Stefan Hagen <stefan@hagen.link>
- added all remaining vulnerabilities outlines - fixed the forgotten additional elements indicators between advisory instance and vulnerabilities element (as document is required and product is pulled in by vulnerabilities and the other way around - removed a few redundant ellipsis indicators when a sequence instance item is followed by the next ellipsis indicating further elements a level above - fixed the mixed occurrences of ampersand and the English 'and' favoring the latter over the fashjionable former Signed-off-by: Stefan Hagen <stefan@hagen.link>
Signed-off-by: Stefan Hagen <stefan@hagen.link>
Signed-off-by: Stefan Hagen <stefan@hagen.link>
Signed-off-by: Stefan Hagen <stefan@hagen.link>
- there is some robustness to aid callers and editors already - the matching of schema snippets and outlines is quite forgiving - in case there are nultiple paths per outline the script gracefully ignores any mismatches in the first path - the identifcation of relevant leaf types is a romantic affair - the output is very verbatim as an exploratory phase is best assisted with - dependency on python-jsonpath is gently reminded when executing without install - crude use of CSAF_JSON_SCHEMA environment variable for locating the schema alike - one could use it in pipelines with grep on ERROR and expecting to not find the pattern Signed-off-by: Stefan Hagen <stefan@hagen.link>
Signed-off-by: Stefan Hagen <stefan@hagen.link>
- added some sub-processing for main-type string in underyling JSON schema - added test for plain enum type Signed-off-by: Stefan Hagen <stefan@hagen.link>
Signed-off-by: Stefan Hagen <stefan@hagen.link>
- works for single file, files, and globs alike - provides summary passing grade per return code of 0 (pass), 1(fail), or 2(usage error) - can now be used in actions more easily Signed-off-by: Stefan Hagen <stefan@hagen.link>
|
@sthagen We don't need the files in |
Signed-off-by: Stefan Hagen <stefan@hagen.link>
done. Thanks for spotting. |
There was a problem hiding this comment.
I like how easy it is to check that as we have all the JSON Path at hand!
I'm sorry about the delayed review.
Some minor comments - mostly editorial - no blocker for that to be merged.
PS: I did not review the rendered files as they are derived from the sources.
| if sub_type := mapping.get('format', ''): | ||
| if sub_type == 'date-time': | ||
| return 'string.datetime' | ||
| if sub_type == 'uri': | ||
| return 'string.uri' | ||
| if 'enum' in mapping: | ||
| return 'string.enum' | ||
| if 'pattern' in mapping: | ||
| return 'string.pattern' |
There was a problem hiding this comment.
String.Const I add now, not sure, how String with both URI and Pattern works here as human readable label though. That one I may have to see and would adapt when we are there (the schema has that combination).
| except KeyError: | ||
| pass | ||
| try: | ||
| return mapping['$ref'].replace('#/$defs/', '$defs.') |
There was a problem hiding this comment.
Shouldn't that be $.$defs (not sure whether that is allowed) or $['$defs'] (definitely allowed) or am I missing something?
There was a problem hiding this comment.
Depends on what we want to achieve. My goal was a nicely globally anchored "you are here and these are your surroundings" feature of a hiking map targeting humans on the right hand side. There I found that for example number: $defs.version_t is more clear than number: $['defs'].version_t (sigil noise) or the "stuttering" number: $.$defs.version_t. The $defs hints at the local definitions nature, and the .version_t exposes the type.
Not sure what the benefit of JSON Paths in the type labels would be. Thus, I went wioth what looked most simple to scann for readers (my way of reading).
But, I have no strong opinion on that one.
There was a problem hiding this comment.
If it is a valid JSON Path, we can keep it that way for now.
| if 'type' in raw_finds: | ||
| return {jpath.split(DOT)[-1]: raw_finds['type']} | ||
| if '$ref' in raw_finds: | ||
| return {jpath.split(DOT)[-1]: raw_finds['$ref'].replace('#/$defs/', '$defs.')} |
There was a problem hiding this comment.
See comment about $defs above.
| ' does not match expected mapping type {vd}' | ||
| ) | ||
| jp_status = FAIL | ||
| elif lt.startswith('$defs.'): |
There was a problem hiding this comment.
May need to be updated as well if we apply the changes above.
csaf_2.1/prose/edit/src/schema-elements-02-props-02-document.md
Outdated
Show resolved
Hide resolved
csaf_2.1/prose/edit/src/schema-elements-02-props-04-vulnerabilities.md
Outdated
Show resolved
Hide resolved
| // ... | ||
| } | ||
| } | ||
| ```yaml <!--json-path($..vulnerabilities..metrics[*].properties)--> |
There was a problem hiding this comment.
I like that as it restricts the path a bit more and removes (potential) ambiguity (which does not exist yet). I wonder whether we should do that in all places applicable ...
|
@sthagen I might have found a bug... If I patch: The result is still: What am I missing? I was under the impression, the tool would check the outlines and report entries that are invalid / have the wrong type according to the schema. Edit: |
Signed-off-by: Stefan Hagen <stefan@hagen.link>
…locks confused the section numbering validator Signed-off-by: Stefan Hagen <stefan@hagen.link>
…ons.md Co-authored-by: tschmidtb51 <65305130+tschmidtb51@users.noreply.github.com>
…ons.md Co-authored-by: tschmidtb51 <65305130+tschmidtb51@users.noreply.github.com>
Co-authored-by: tschmidtb51 <65305130+tschmidtb51@users.noreply.github.com>
Co-authored-by: tschmidtb51 <65305130+tschmidtb51@users.noreply.github.com>
…t-name.md Co-authored-by: tschmidtb51 <65305130+tschmidtb51@users.noreply.github.com>
…up-id.md Co-authored-by: tschmidtb51 <65305130+tschmidtb51@users.noreply.github.com>
…ups.md Co-authored-by: tschmidtb51 <65305130+tschmidtb51@users.noreply.github.com>
…ities.md Co-authored-by: tschmidtb51 <65305130+tschmidtb51@users.noreply.github.com>
|
@tschmidtb51 there have to be bugs. Severe bugs. This tool should be a helper for us and was created along my explorations of how to create something outlinish, still valid YAML and mapping to the simplified types of the JSON Path results from the schema. I would like to clean up the tool and then we can fix enhance the tool as maintenance / tool changes. The goal was to not first inject nice outlines in YAML look everywhere and then llater explore if we can assess these, but to do this in lockstep. Some deviations that are obviously wrong it does not detect. Some rare places where we have the upstream sources for CVSS (I think) encoded in some made up "variables" like annotations in the outlines it may never do so. But, compared to our made up JSON skeletons we had before, I think we are in a much more verifiable position now. |
Signed-off-by: Stefan Hagen <stefan@hagen.link>
|
Motion set: https://groups.oasis-open.org/discussion/motion-for-the-presentation-enhancement-proposal-1221 on 2026-03-01 and seconded on 2026-03-04. |
|
|
Please cf. with proposal "Initial steps to enhance the presentation of the CSAF model" (#1220) for examples and the rationale behind this change-set.
Material Changes
None.
Editorial Changes
outlines/*.yaml)Maintenance Changes