feedback: version SLSA 1.0 dropping / reducing scope from 0.1 is weird

[msmeissn]

Sorry for not keeping up with the SLSA 1.0 development.

It looks weird to me that you would declare it SLSA 1.0.

• it has less requirements and reduced scope compared to 0.1
• quite some work (and big open gaps) is only planned to be filled again for the future past 1.0
• it severely devalues adoption work done by early adopters of SLSA 0.1 (like my employer SUSE)

So I would suggest not calling it SLSA 1.0.

• 1.0 would suggest completeness which is not the case. Perhaps 0.2 might fit better.
• if you want to stick with the 1.0, you could call it differently to match content, e.g. "SLSA Build 1.0"

[MarkLodato]

Hi @msmeissn. I'm sorry about your disappointment in v1.0, but please let me try to explain the rationale. See also https://github.com/slsa-framework/slsa-proposals/tree/main/0003#postpone-definition-of-slsa-4.

The intent of the "1.0" version identifier is to denote stability, not completeness. We are confident that the subset that we have released represents broad consensus and will not change significantly in the future. The rest of v0.1 (e.g. hermeticity, source code retention, two-party review), on the other hand, had caused a lot of confusion and disagreement. I'd estimate that fixing those issues will take at least another year. (Already v1.0 has taken almost a year, and there weren't even any major disagreements!) Meanwhile, many organizations are waiting for a stable v1.0 to begin to work on SLSA at all.

Our main concern is stability. If we call something "SLSA Level X" today, then change Level X's requirements tomorrow, it becomes extremely confusing what "Level X" means. The purpose of SLSA is to provide a stable way to describe levels of security. We need to be fairly confident that we get the levels right before calling something v1.0.

Therefore, we had a choice: either release a stable v1.0 now with only a (frankly disappointing) subset of what we ultimately want to achieve, or delay it for another year while we try to make it "complete". The overwhelming feedback has been that people want v1.0 now. For most organizations, the higher SLSA levels and the source requirements are a stretch anyway, so defining a stable Build L1-3 allows us to make meaningful progress while solidifying the rest of the specification.

I disagree that v1.0 devalues adoption work by early adopters of v0.1. We're not saying the other aspects are not important, just that they are hard problems that we have not yet agreed upon how to solve. My organization (Google) has also done the rest of SLSA v0.1 for many years, and we're not stopping that work simply because SLSA v1.0 does not describe it yet. If anything, SUSE can claim that it's above and beyond what SLSA describes today.

Anyway, I hope this at least helps you understand why we landed where we did.

[msmeissn]

Mark, thank you for this explanation!

Yes, SUSE will not be stopping or downgrading their efforts (as we also use it to comply to our Common Criteria and ISO certifications).

[david-a-wheeler]

@msmeissn - as @MarkLodato noted, the point of 1.0 is stability not completeness. The current plan is to continue to work to gain consensus on the specifics beyond 1.0, and we'd welcome your help in doing so!