CVE Schema: could not generate type for field "...": definition does not exist in schema:

[beyer-stefan]

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?

[omissis]

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?

[ytjohn]

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"
  ]
}

[ytjohn]

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"
    ]
  }
}

[omissis]

@ytjohn thanks for taking the time to investigate! I will look into it 🙏

[ytjohn]

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"
      ]
    },

[ytjohn]

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)
        }