VSA: should policy digest be mandatory

[laurentsimon]

Only the uri field is mandatory. Why is the digest not? Do we expect the uri to not be hashable in some scenarios?

I also wonder whether we should allow a version field. I would expect that policies will evolve over time. Or maybe we expect the policy to be renamed to reflect changes?

[laurentsimon]

If resourceDescriptor has a version field, we could use it for the policy too.

[MarkLodato]

I don't think we should make it required because it is not necessary for correct use of the VSA. It might not be straightforward to hash it. For example, if the policy is a combination of a per-package config plus some global config, you need to define a canonical serialization of both to represent it.

[laurentsimon]

I was suspecting the policy may not be hash-able, thanks for confirming. Fwiw, in your example, the base policy could be part of the final policy, like a base image is part of a final image in a dockerfile. In this case the serialization is kinda free. But not everyone may use this model.

[MarkLodato]

Here's a concrete example: the "policy" is that the new version must have provenance matching the previous version. There is no recorded policy anywhere; it's just a comparison to the previous version. Technically this creates a policy on the fly based on the previous version's provenance, but it is never serialized anywhere. One could define a canonical serialization and hash it, and perhaps that's a good idea, but it's not necessary for correct operation. Thus making it REQUIRED in the spec seems like an overstep.

I think a good compromise is to change from:

The entry MUST contain a uri.

to:

The entry MUST contain a uri identifying which policy was applied and SHOULD contain a digest to indicate the exact version of that policy.

[laurentsimon]

SGTM