search

slsa-framework / slsa

Supply-chain Levels for Software Artifacts
https://slsa.dev
Other
1.49k stars 214 forks source link

Clarify Attestation Immutability #1016

Open chizou opened 6 months ago

chizou commented 6 months ago

The description Immutability of Attestationssay attestations SHOULD be immutable, but doesn't clarify why it's a SHOULD and not a MUST. This PR suggests because "SLSA-conformant system" is ill-defined. It might help to clarify that on the Immutability of Attestations page.

I also had a discussion with @arewm that there might be reasons where differing levels of transparency might be desired. It would be helpful to expand on use case of differing levels of transparency to include when it's necessary and what the levels might be.

Without this additional context, it's unclear why it's a SHOULD and not a MUST

MarkLodato commented 6 months ago

@di, do you remember the reasoning behind the following recommendation? We should update the text to explain.

Attestations SHOULD be immutable. Once an attestation is published as it corresponds to a given artifact, that attestation is immutable and cannot be overwritten later with a different attestation that refers to the same artifact. Instead, a new release (and new artifacts) SHOULD be created.

arewm commented 6 months ago

It was changed to MUST in review: https://github.com/slsa-framework/slsa/pull/673#discussion_r1131506810

and then backed out to SHOULD when the decision was made to avoid the MUST language in distributing provenance: https://github.com/slsa-framework/slsa/pull/789

Some potential rationale for a SHOULD here is if provenance is published from a private builds system but in a sanitized form. A VSA could also be used in this situation to maintain provenance immutability.