/area release-eng
refers to kubernetes/sig-release#1724, #3031

The initial draft of the sining KEP is proposed in #3061

Given the unknown unknowns, and the context of a SIG Release 2021 (and beyond) vision/roadmap, I believe it would make sense to set a more concrete and limited scope first KEP for "SLSA Level 3 Compliance". Level four feels notably harder to accomplish in many contexts (but I'm hopeful it wont be tremendously hard in our specific context, maybe naive?). Level three feels readily attainable for the Kubernetes project. And even at that it will also take a considerable amount of effort and time while also bringing into high clarity what would actually be required for level four compliance.

This would also have the benefit of removing the ambiguous split graduation criteria currently in https://github.com/kubernetes/enhancements/pull/3051/files#diff-1f8352f993f9069e41c3ce0f07a3e5ae5c6f58b87acf834b8cf9099fbc6fcc68R379

And it sets a high bar while allowing a reasonable time bound on expected delivery. "SLSA compliance" without a number in the phrase can mean anything from "SLSA level-0 compliant" up to "SLSA level-4 compliant", and I very much hope we intend to do more than level 0.

Thanks for the comments @tpepper. I agree completely. I did not want to give up before declaring level 4 as unimplementable, but I agree that for now, it is not realistic to consider it. But we can always finish this and push forward.

I've retitled the KEP and scoped it to level 3. I have also removed the dual graduation criteria. Thank you !

I'd agree with this - SLSA4 was designed to be very aspirational from the start. Just my personal take - but I'd either expect some intermediate levels or massive changes in tooling to pop up before SLSA4 is realistic for most projects.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

Related proposal from CNCF that might be able to help here: cncf/tag-security#890

We still have to define which deliverables will land in v1.25, especially in combination with the signing KEP.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

@puerco are there any bits we want to achieve in v1.27?

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

Just an FYI, because some folks have missed the announcements. If all goes as planned SLSA 1.0 releases on April 19th, 2023. There are a few changes to what SLSA 3 compliance would look like. See release candidate 2: https://slsa.dev/spec/v1.0-rc2/

The SLSA community is also interested in helping out anyway we can in helping making the adoption of SLSA 3 v1.0 as simple and straightforward as possible. How can we help? Are there meetings we should attend?

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale