bug: additional properties on property type in JSON

[agschrei]

Currently the definition for a property expects keys name and value but neither of them is required and the presence of other keys is not prohibited through a constraint like "additionalProperties": false

This is an inconsistency compared to other types defined on the schema such as component or dependency which disallow additional properties.

Concretely, that means this sample SBOM validates against the schema, but my argument is that it should not:

{
  "$schema": "http://cyclonedx.org/schema/bom-1.4.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "metadata": {
    "component": {
      "bom-ref": "foo",
      "type": "application",
      "name": "foo",
      "properties": [
        {
          "name": "myCustomProperty",
          "value": "myCustomValue",
          "abc": ["def"]
        }
      ]
    }
  },
  "components": [
    {
      "bom-ref": "foo/bar",
      "type": "library",
      "name": "bar"
    }
  ]
}

https://www.jsonschemavalidator.net/s/dRHUBrfG

This seems like a small thing, but I just spent an hour trying to figure out why cyclonedx-core-java would validate an sbom just fine but then fail to parse it. So I think the spec would benefit from a stronger constraint on the property type.

I'm happy to contribute the spec changes for 1.6 if this gets approved.

[jkowalleck]

checked, can confirm for JSON:

• name optional
• value optional
• additional properties allowed
• see

  specification/schema/bom-1.4.schema.json

  Lines 1147 to 1162 in 8af880d

  	"property": {
  	"type": "object",
  	"title": "Lightweight name-value pair",
  	"properties": {
  	"name": {
  	"type": "string",
  	"title": "Name",
  	"description": "The name of the property. Duplicate names are allowed, each potentially having a different value."
  	},
  	"value": {
  	"type": "string",
  	"title": "Value",
  	"description": "The value of the property."
  	}
  	}
  	},

in contrast to the JSON, the XML defines

• name is mandatory
• value is implicit kind of optional (implicit allows empty string)
• no additional properties/children allowed
• see

  specification/schema/bom-1.4.xsd

  Lines 1721 to 1734 in 8af880d

  	<xs:complexType name="propertyType">
  	<xs:annotation>
  	<xs:documentation>Specifies an individual property with a name and value.</xs:documentation>
  	</xs:annotation>
  	<xs:simpleContent>
  	<xs:extension base="xs:normalizedString">
  	<xs:attribute name="name" type="xs:string" use="required">
  	<xs:annotation>
  	<xs:documentation>The name of the property. Duplicate names are allowed, each potentially having a different value.</xs:documentation>
  	</xs:annotation>
  	</xs:attribute>
  	</xs:extension>
  	</xs:simpleContent>
  	</xs:complexType>

in contrast to JSON, the Protobuff defines

• name is mandatory
• value is optional
• no additional properties/children allowed
• see

  specification/schema/bom-1.5.proto

  Lines 606 to 609 in 8af880d

  	message Property {
  	string name = 1;
  	optional string value = 2;
  	}

[jkowalleck]

@stevespringett if the XML & ProtoBuff are the intended solutions,
should I target a bug fix of the JSON for the upcoming v1.6 then?

[stevespringett]

Yes please. Thanks @jkowalleck

[agschrei]

Thanks to both of you for the quick turnaround on this!

[stevespringett]

Thanks for reporting @agschrei . Fix will be included in the upcoming v1.6 specification.