Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for SLSA 1.0 predicate #2860

Closed
mlieberman85 opened this issue Apr 4, 2023 · 6 comments
Closed

Add support for SLSA 1.0 predicate #2860

mlieberman85 opened this issue Apr 4, 2023 · 6 comments
Labels
enhancement New feature or request

Comments

@mlieberman85
Copy link
Contributor

Cosign supports the v0.2 SLSA predicate through the --type slsaprovenance flag on the attest and attest-blob commands. SLSA 1.0 Release Candidate 1 (RC1) is out and RC2 should be coming out today. By the end of this month (April 2023) it is expected that SLSA v1.0 will be officially released. We don't expect any new major changes to the SLSA provenance predicate.

For reference, here's the specification for the predicate: https://slsa.dev/provenance/v1-rc1

@developer-guy
Copy link
Member

developer-guy commented Apr 5, 2023

AFAIK, cosign uses in-toto-golang (v0.0.7) to consume spec. And I saw that PR by @asraa merged to the next branch of that project. So, once the newest version of in-toto-golang is released with the SLSA v1 support, we'll update the in-toto-golang dep on cosign side and make necessary updates based on that spec.

@mlieberman85
Copy link
Contributor Author

Thank! I'll check the ticket there.

@haydentherapper
Copy link
Contributor

V1 support merged - in-toto/in-toto-golang#223

@schoudhury
Copy link

any updates on this issue getting addressed? we at harness are looking to use cosign for slsa provenance generation and want to make sure we adhere to the slsa 1.0 spec

@haydentherapper
Copy link
Contributor

No progress, though it should be straightforward to implement. We should make sure we continue to support verifying 0.2 attestations.

@ziel
Copy link
Contributor

ziel commented Aug 22, 2023

I'm interested in writing a PR for this if it's not active... I probably won't have a chance to get to it until next week though. Is there any process I should follow to prevent overlapping if I start working on it?

Also: would it make sense to add this as --type slsaprovenance1.0 to leave --type slsaprovenance for backwards compatibility? Or, how would people like to see that done?

lance pushed a commit to securesign/cosign that referenced this issue Sep 25, 2023
…store#3219)

* Add SLSA 1.0 attestation support to cosign

Signed-off-by: Canaan Silberberg <[email protected]>

* fix leading whitspace

Signed-off-by: Canaan Silberberg <[email protected]>

* fix 1.0 typo

Signed-off-by: Canaan Silberberg <[email protected]>

* add slsaprovenance02 type

Signed-off-by: Canaan Silberberg <[email protected]>

---------

Signed-off-by: Canaan Silberberg <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants