b369b02f4f
* feat: expose rpm signature information This helps with more confident identification of an rpm. In theory, two rpms can be built that have the same purl string, and otherwise look identical in syft's output, but the PGP information would distinguish them as signed either by different keys, or signed at different times. In practice, this usually makes no difference since rpms tend to have unique name/version/release strings. This just gives increased confidence about the identity of the rpm found in the db. Signed-off-by: Ralph Bean <rbean@redhat.com> * chore: generate json schema Signed-off-by: Ralph Bean <rbean@redhat.com> * re-generate json schema Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com> * rename to a more generic signature field Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com> * rename rpm.pgp to rpm.signatures Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com> * split out signature fields Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com> * bump json schema Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com> * include RPM archives Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com> * update json schema Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com> * dont fail on unknown signature type Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com> --------- Signed-off-by: Ralph Bean <rbean@redhat.com> Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com> Co-authored-by: Alex Goodman <wagoodman@users.noreply.github.com>
JSON Schema
This is the JSON schema for output from the JSON presenters (syft packages <img> -o json). The required inputs for defining the JSON schema are as follows:
- the value of
internal.JSONSchemaVersionthat governs the schema filename - the
Documentstruct definition withingithub.com/anchore/syft/syft/formats/syftjson/model/document.gothat governs the overall document shape - generated
AllTypes()helper function within thesyft/internal/sourcemetadataandsyft/internal/packagemetadatapackages
With regard to testing the JSON schema, integration test cases provided by the developer are used as examples to validate that JSON output from Syft is always valid relative to the schema/json/schema-$VERSION.json file.
Versioning
Versioning the JSON schema must be done manually by changing the JSONSchemaVersion constant within internal/constants.go.
This schema is being versioned based off of the "SchemaVer" guidelines, which slightly diverges from Semantic Versioning to tailor for the purposes of data models.
Given a version number format MODEL.REVISION.ADDITION:
MODEL: increment when you make a breaking schema change which will prevent interaction with any historical dataREVISION: increment when you make a schema change which may prevent interaction with some historical dataADDITION: increment when you make a schema change that is compatible with all historical data
Adding a New pkg.*Metadata Type
When adding a new pkg.*Metadata that is assigned to the pkg.Package.Metadata struct field you must add a test case to cmd/syft/internal/test/integration/catalog_packages_cases_test.go that exercises the new package type with the new metadata.
Additionally it is important to generate a new JSON schema since the pkg.Package.Metadata field is covered by the schema.
Generating a New Schema
Create the new schema by running make generate-json-schema from the root of the repo:
- If there is not an existing schema for the given version, then the new schema file will be written to
schema/json/schema-$VERSION.json - If there is an existing schema for the given version and the new schema matches the existing schema, no action is taken
- If there is an existing schema for the given version and the new schema does not match the existing schema, an error is shown indicating to increment the version appropriately (see the "Versioning" section)
Note: never delete a JSON schema and never change an existing JSON schema once it has been published in a release! Only add new schemas with a newly incremented version. All previous schema files must be stored in the schema/json/ directory.