CVE Schema: could not generate type for field "...": definition does not exist in schema:
beyer-stefan opened this issue · 6 comments
I am trying to make CVE JSON 5.0 bundle.json from CVE Schema work, but I run into: go-jsonschema: Failed: could not generate type for field "metrics": could not generate type for field "cvssV2_0": could not generate type for field "accessComplexity": definition does not exist in schema: "metrics/items/properties/cvssV2_0/definitions/accessComplexityType" (from ref "#/definitions/metrics/items/properties/cvssV2_0/definitions/accessComplexityType")
As far as I can tell accessComplexityType
does exist.
Does anybody have an idea what I am missing here?
hi @beyer-stefan can you please share the command you are using (including all the flags and masking the base paths of your filesystem) please?
What version of go-jsonschema were you using?
I am running into a very similar issue with netbox schema, and found this issue. I replicated @beyer-stefan 's issue using v0.15.0.
wget https://raw.githubusercontent.com/CVEProject/cve-schema/master/schema/v5.0/docs/CVE_JSON_5.0_bundled.json
go-jsonschema -p cve CVE_JSON_5.0_bundled.json
Produces this error:
go-jsonschema: Failed: could not generate type for field "metrics": could not generate type for field "cvssV2_0": could not generate type for field "accessComplexity": definition does not exist in schema: "metrics/items/properties/cvssV2_0/definitions/accessComplexityType" (from ref "#/definitions/metrics/items/properties/cvssV2_0/definitions/accessComplexityType")
The definition does exist.
cat CVE_JSON_5.0_bundled.json | jq '.definitions.metrics.items.properties.cvssV2_0.definitions.accessComplexityType'
{
"type": "string",
"enum": [
"HIGH",
"MEDIUM",
"LOW"
]
}
My issue with the netbox schema may be related.
wget https://raw.githubusercontent.com/netbox-community/devicetype-library/master/schema/generated_schema.json
wget https://raw.githubusercontent.com/netbox-community/devicetype-library/master/schema/components.json
If you do go-jsonschema -p netbox generated_schema.json -o netbox.go
that works fine and produces code for ConsolePort
type ConsolePort struct {
// Type corresponds to the JSON schema field "type".
Type *ConsolePortType `json:"type,omitempty" yaml:"type,omitempty" mapstructure:"type,omitempty"`
}
type ConsolePortType string
const ConsolePortTypeDb25 ConsolePortType = "db-25"
But if you do the same for components.json, which references that console-port in generated_schema.json, it fails. I did wonder if the dash in netbox's schema was an issue (requires extra quotes with jq command), but I removed all the dashes and got a dashless version of the same error.
go-jsonschema -p netbox components.json
Produces error:
go-jsonschema: Failed: could not generate type for field "type": definition does not exist in schema: "console-port/properties/type" (from ref "generated_schema.json#/definitions/console-port/properties/type")
$ cat generated_schema.json| jq '.definitions."console-port".properties'
{
"type": {
"type": "string",
"enum": [
"de-9",
"db-25",
"rj-11",
"rj-12",
"rj-45",
"mini-din-8",
"usb-a",
"usb-b",
"usb-c",
"usb-mini-a",
"usb-mini-b",
"usb-micro-a",
"usb-micro-b",
"usb-micro-ab",
"other"
]
}
}
I poked at this a bit more today. It seems like it's the depth level.
In the netbox-comunity schema, if I rewrite generated_schema.json like so
"type": "string",
"enum": [
"de-9",
"db-25",
"rj-11",
"rj-12",
"rj-45",
"mini-din-8",
"usb-a",
"usb-b",
"usb-c",
"usb-mini-a",
"usb-mini-b",
"usb-micro-a",
"usb-micro-b",
"usb-micro-ab",
"other"
]
},
"console-port": {
"type": "object",
"properties": {
"type": {
"$ref": "#/definitions/console-port-properties"
}
}
},
"console-server-port": {
"type": "object",
"properties": {
"type": {
"$ref": "#/definitions/console-port-properties"
}
}
},
And in components.json I would repoint the references, I can read these and move forward. Of course, I'd have to do this to every second level down.
"definitions": {
"console-port": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"label": {
"type": "string"
},
"type": {
"$ref": "generated_schema.json#/definitions/console-port-properties"
},
"poe": {
"type": "boolean"
}
},
"required": [
"name",
"type"
]
},
"console-server-port": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"label": {
"type": "string"
},
"type": {
"$ref": "file://generated_schema.json#/definitions/console-port-properties"
}
},
"required": [
"name",
"type"
]
},
Hello again. Thanks this great library. I now realize this is a known issue, or the very least, related to a known issue.
From the README, nested names aren't supported yet.
References against nested names: #/$defs/someName/$defs/someOtherName
I thought this meant included a nested def from somewhere else in the file. But - it does seem to apply equally well to properties. And indeed in the code, there is a TODO item for this. The top level names work, but properties is part of a sub-path.
I wrote some rather horrible code for properties. This works "for me", but seems like the wrong approach (splitting the string).
// TODO: Support nested definitions.
var ok bool
// handle properties as a definition name
if strings.Contains(defName, "/properties/") {
defName, propName := defName[:strings.Index(defName, "/properties/")], defName[strings.Index(defName, "/properties/")+len("/properties/"):]
if def, ok = schema.Definitions[defName]; ok {
// this means we got the definition, but we need to get the property
// we should also do modify the error message if it's the property that is missing
def, ok = def.Properties[propName]
}
} else {
def, ok = schema.Definitions[defName]
}
if !ok {
return nil, fmt.Errorf("%w: %q (from ref %q)", errDefinitionDoesNotExistInSchema, defName, ref)
}