Workstream: Release SLSA v1.1

[kpk47]

This is a tracking issue for releasing v1.1. The primary goal of v1.1 is to release small updates to v1.0 to address issues that are too significant for an in-place update to v1.0 yet we don't want to block until the next significant release.

Workstream shepherd: Joshua Lock (@joshuagl)

Sub-issues:

• Resolve ambiguity in ResourceDescriptor annotations #875
• Make more VSA fields optional, add verification section #878
• VSA: can we be more consistent with SLSA fields and VSA fields #809
• VSA: should policy digest be mandatory #803
• VSA: file extension recommendation #804
• VSA: under-specified resource_uri #808
• Clarifying values of verifiedLevels in VSA v1 #968

[kpk47]

I think most of the urgency is gone since in-toto changed the spot where there was a conflict between the two specs. #882 and #892 could be enough for a v1.1 release, so I guess the question is what else we would add if we waited.

[joshuagl]

I think we should aim to have a patch release soon.

We could include:

• content: schema are informative, spec text is canonical #892
• editorial: Clarify language in VSA spec #882
• content: add a verifier version field to VSA #905

What other changes should we consider?

[laurentsimon]

If VSA is part of this release, it would be useful to resolve other VSA issues - at least those we consider blocking and / or a that resolving them may be backward-incompatible

[MarkLodato]

Created the v1.1 directory in #942

[joshuagl]

If VSA is part of this release, it would be useful to resolve other VSA issues - at least those we consider blocking and / or a that resolving them may be backward-incompatible

Do you have any particular issues in mind? I took a look at the issues backlog and identified the following VSA related items:

• Clarifying values of verifiedLevels in VSA v1 #968
• VSA: under-specified resource_uri #808
• VSA: file extension recommendation #804
• VSA: should policy digest be mandatory #803 -- I just filed a PR for this one (content: recommend a VSA include the policy's digest #979)

[MarkLodato]

Joshua, could you add those issues to the top post? I just created a template there. If you use that format, GitHub links them bi-directionally, which is nice.

[joshuagl]

Good tip. Done, thanks.

[TomHennen]

I'm curious about how we're feeling about this issue's representation of what's in scope for SLSA 1.1. The issue suggests they'll just be small clarifications but then we're also working on the source track, a new build level etc...

Is there anything else we're trying to get in to a 1.1 release?

[joshuagl]

Good question, I asked something similar when reviewing the first draft of the Source track. I'd missed a discussion on this very topic in a working meeting which Arnaud summarised:

Final thought, is adding a new level appropriate for a minor release, or should we consider a major release for this?

We've talked about this on Monday's call actually. We agreed to punt on this issue for now and wait until we decide to publish the next version of the spec. We can then discuss what change to the version number is the most appropriate based on what ends up being in the spec. For now we can still work on "1.1" without it being binding.

We could try and get a release (1.1?) out sooner while we continue to work on the source track and new build level. Would that be useful? Are there things that SLSA adopters are seeking clarity on which would benefit from a "minor" release?

[TomHennen]

I think I'm mostly trying to understand what's left to do for 1.1 and how badly things get left behind that don't make it to 1.1.

E.g. I think it's unlikely the 'dependency track' would be complete for 1.1. So what would the path forward be?