Update doc for SLSA Statement generation

Fabien Catteaurequested to merge
fcatteau-master-patch-73699 into master

What does this MR do?

Clarify that the Artifact provenance metadata produced by the runner is an SLSA Statement really. The statement binds build artifacts to provenance metadata, so it includes an SLSA Provenance but is NOT the provenance itself. See https://slsa.dev/spec/v1.0/attestation-model

NOTE: Artifact provenance metadata hasn't been renamed. This way doc sections and links don't need to be updated. This could be done in a follow-up MR.

Un-document SLSA_PROVENANCE_SCHEMA_VERSION. This CI variable still exists, but v1 is the only supported value, and anything else will trigger an error. See https://gitlab.com/gitlab-org/gitlab-runner/-/blob/15a1b9fc9b7cc97759ff2cbbd2dbd04777ebe8a8/commands/helpers/artifact_metadata.go#L65

Fix/update default values for statement _type and provenance predicateType. Right now the runner generates a statement in the in-toto v0.1 format, and that statement includes a provenance in the SLSA 1.0 Provenance format This is hardcoded in https://gitlab.com/gitlab-org/gitlab-runner/-/blob/15a1b9fc9b7cc97759ff2cbbd2dbd04777ebe8a8/commands/helpers/artifact_metadata.go#L134 and https://gitlab.com/gitlab-org/gitlab-runner/-/blob/15a1b9fc9b7cc97759ff2cbbd2dbd04777ebe8a8/commands/helpers/artifact_metadata.go#L65.

Support for the SLSA v0.2 Provenance format was removed as part of gitlab-runner!4760 (merged).

Related issues

None.

Author's checklist

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

  • ~"frontend"
  • ~"backend"
  • ~"type::bug"
  • ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

  • If the content requires it, ensure the information is reviewed by a subject matter expert.
  • Technical writer review items:
    • Ensure docs metadata is present and up-to-date.
    • Ensure the appropriate labels are added to this MR.
    • Ensure a release milestone is set.
    • If relevant to this MR, ensure content topic type principles are in use, including:
      • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
      • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
      • Any task steps should be written as a numbered list.
      • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
  • Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.
Edited by Fabien Catteau

Merge request reports