Think about autodiscover material type

[javirln]

The goal of the task is to be able to automagically discover the kind of material being added to the attestation. It can be run executed by setting the flag --auto-discover (pending to agree the actual name) on the attestation add ... command.

[javirln]

Right now all validations are happening on each material type crafter. Such validations are enclosed in the Craft method from the Craftable interface.

The idea would be to create a new interface o reuse an existing one where it forces a method with the following signature:

type CraftableValidation interface {
  Validate(filepath string) error
}

Having such method can help us to run validations in a cascade way from the most stricter to weaker until one is found:

// Test all types of CraftingSchema_Material_MaterialType
resType := schemaapi.CraftingSchema_Material_MATERIAL_TYPE_UNSPECIFIED.String()

crafters := []struct {
	crafter CraftableWithValidation
	resType string
}{
	{&JUnitXMLCrafter{}, schemaapi.CraftingSchema_Material_JUNIT_XML.String()},
	{&OpenVEXCrafter{}, schemaapi.CraftingSchema_Material_OPENVEX.String()},
	{&HelmChartCrafter{}, schemaapi.CraftingSchema_Material_HELM_CHART.String()},
	{&CyclonedxJSONCrafter{}, schemaapi.CraftingSchema_Material_SBOM_CYCLONEDX_JSON.String()},
        ...
}

for _, entry := range crafters {
	if err := entry.crafter.Validate(materialValue); err == nil {
		resType = entry.resType
		break
	}
}

return resType

Steps to follow

The only input received from the users is the value. This value can be both a string or a filepath pointing to a file in the system. Therefore there are two branches to follow; the value represents a file or not. The general action would be to go from the most stricter to the weaker in terms of validations.

Each branch will have its own order of validating preference.

Value not representing a file

Two options, it can be either a type STRING or CONTAINER_IMAGE. Since CONTAINER_IMAGE is the stricter, it will go first.

1. CONTAINER_IMAGE
2. STRING

Value representing a file

When the value is representing a file, the validation start again, from stricter to weaker.

1. HELM_CHART
2. CSAF_*
3. SBOM_CYCLONEDX_JSON
4. SBOM_SPDX_JSON
5. OPENVEX
6. SARIF
7. JUNIT_XML
8. ATTESTATION
9. EVIDENCE ARTIFACT

There are though two problems:

• CSAF_* materials have different kind but same validation for all of them except from the category if they have it set
• EVIDENCE and ARTIFACT are the ones with weaker validation, basically they don't have any

[javirln]

After a chat with @migmartri we have decided to go for the following:

• Prevent the auto discover of STRING type and remove the fallback to EVIDENCE and promote ARTIFACT for default.
• Instead of implementation any other interface, since have Crafter.AddMaterialContractFree, leverage that method to iterate all over all types.

[javirln]

By default attestation add will try to discover the material kind based on its known types.