Move "x_generator" to an official and optional string value "generator"

[jayjacobs]

I suggest, as a way to standardize this field across different tools and more importantly, json records, that we add the "generator" field as a string into the "cveMetadataPublished" definition, and move away from the experimental field for the same purpose.

This is related to, but independent from #318

To be inserted into the properties of the cveMetadataPublished definition (and not required):

generator: {
    type: "string",
    description: "An identifying string for any software used to generate or maintain this record, e.g. \"Vulnogram 0.2.0\".",
    minLength: 1,
    maxLength: 256
},

And leave the field as optional.

[ccoffin]

Probably should make this official in the CVE Record Format. Maybe just define this as stated use what Vulnogram provides today for structure.

[zmanion]

Not to overcomplicate things, but do we want a separate field for generator version? Also is "engine" an unnecessarily weird word?

Current:

"x_generator": {
  "engine": "Vulnogram 0.2.0"
}

Proposed:

"generator": {
  "name": "Vulnogram",
  "version": "0.2.0"
}

[MrMegaZone]

Not to overcomplicate things, but do we want a separate field for generator version? Also is "engine" an unnecessarily weird word?

"generator": {
"name": "Vulnogram",
"version": "0.2.0"
}

I do think name & version are better. 'Engine' never really made sense to me.

I'm not sure if it is possible, but I'd say name is optional, and version is optional but is only valid when name is also present. That way we don't get weirdness with just a 'version' being provided and no name.

[mprpic]

+1 for separate name and version. That is also how the CSAF specification uses this, see e.g.: https://github.com/oasis-tcs/csaf/blob/bdc1381881beeba2a03a6321f37febc9c5794ec5/csaf_2.0/examples/csaf/rhsa-2022_0011.json#L62-L65

[MrMegaZone]

+1 for separate name and version. That is also how the CSAF specification uses this, see e.g.: https://github.com/oasis-tcs/csaf/blob/bdc1381881beeba2a03a6321f37febc9c5794ec5/csaf_2.0/examples/csaf/rhsa-2022_0011.json#L62-L65

Interesting - maybe we should borrow a bit from CSAF:

 "generator": {
        "date": "2022-03-23T20:31:00Z",
        "engine": {
          "name": "Red Hat SDEngine",
          "version": "3.4.3"
        }
      },