SLSA v1.0: Release Candidate 1

[MarkLodato]

This issue tracks the release candidate 1 (RC1) of the SLSA v1.0 specification.

The bar for RC1 is that someone can read it and understand the most important concepts. Our goal is to get someone shipped ASAP to allow reviewers to start providing feedback while we polish the rest. It's OK for there to be minor inconsistencies or poor explanations that a motivated reader can get past. A blocker for RC1 would be something like a major missing concept or a major inconsistency, such as referring to code review (present in v0.1 but deferred for v1.0).

Outstanding blockers:

• v1.0: Clarify that systems are manually verified, artifacts are automatically verified #130
  • Includes subtasks
  • The actual conformance program is out of scope; just clarifying that there exists some means to establish trust in a builder.
• Provenance v1.0 - verification section
• Add a "What's New?" page to the spec for SLSA 1.0 #592
  • Most reviewers will be familiar with v0.1, so it will significantly help their review if we summarize the differences.
• Move references to source track and Build L4 from requirements #605
  • Blocking because we're claiming v1.0 is stable, yet we have a huge "not yet defined" section
• Any other P0s from the project board?
• Any other TODOs?
• Create versioned directory "v1.0-rc1".

Deferred:

• Maybe additional work on verifying artifacts w.r.t. package ecosystems?
• Task: Update threats.md for SLSA v1.0 #567
• Move "use cases" to the spec #580

[MarkLodato]

In order to get RC1 out the door, should we defer #567 (threats.md) until after RC1?

[inferno-chromium]

In order to get RC1 out the door, should we defer #567 (threats.md) until after RC1?

Seems fine to defer, that can come later.

[MarkLodato]

I suggest that we cut a release this week. So:

• Merge outstanding PRs
• Add a "What's New?" page to the spec for SLSA 1.0 #592
• Add "RFC" callouts for things that we know are not yet settled.
• Create versioned URL "v1.0-rc1" so that it doesn't change while people review. (Also make that non-hidden.)
• Blog post

[di]

Add "RFC" callouts for things that we know are not yet settled.

Can you add more detail about what you're imagining here? Is this about turning existing TODOs into some sort of callout?

[kpk47]

@di The main point we want feedback on is whether verification/expectations should remain in the build track or be split out. You do raise a good point about existing TODOs though. We can collect them into issues when we cut the RFC so the community has a place to comment on them.