Skip to content

Discussion: Retention policy for SLSA attestations

Based on the discussion around data lifecycle in this MR, I think it would make sense to determine a retention policy for SLSA attestations.

As described in the SLSA L3 design document, attestations are required as part of the verification workflow, and artifact verification will fail if an attestation is not available.

Because the artifacts being verified may be hosted or distributed outside of GitLab, we can't rely on artifact existence in GitLab to determine if an attestation is still active because the artifact may be published elsewhere even if the job artifact has been removed from GitLab.

Here are two proposed solutions for discussion:

  1. Set a project limit (like 1k-3k) for number of attestations allowed, and purge the oldest when the limit it reached. Most projects only have a limited number of supported releases, so setting it to a number above 1k should ensure the attestations are preserved for supported releases.
  2. Track a last_accessed_on date for each attestation and remove the attestation if it hasn't been accessed for over a year. If a package hasn't been verified in over a year, it is likely no longer a supported package.

There may be other ways to design a retention policy. WDYT @jocelynjane @fcatteau @mmishaev @sroque-worcel @ahuntsman