-
Notifications
You must be signed in to change notification settings - Fork 29
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
in-toto 1.0 support #60
Comments
Resource Descriptors from intoto 1.0 are now enabled by default while generating the attestation. Example "materials": [
{
"annotations": {
"chainloop.material.name": "built-site",
"chainloop.material.type": "ARTIFACT"
},
"digest": {
"sha256": "8bc35ddb97188d9501031e400bc1b59e5ecc772ba49efcff7961e2c5206bc66f"
},
"name": "578779893f6a53e029b388ecf5bfee93e07da5fe-build.tar.gz"
},
{
"annotations": {
"chainloop.material.name": "sbom-cdx",
"chainloop.material.type": "SBOM_CYCLONEDX_JSON"
},
"digest": {
"sha256": "9773b40f606e42d0ef819c7cb57d5d040251e7fe8f3c5e2a2c0b916259fef231"
},
"name": "sbom.cyclonedx.json"
},
{
"annotations": {
"chainloop.material.name": "sbom-spdx",
"chainloop.material.type": "SBOM_SPDX_JSON"
},
"digest": {
"sha256": "b2b144c6535f2e91b26c262bbb51c64771ef1b2ac8f4ff6cd2a875ecdee0ce97"
},
"name": "sbom.spdx.json"
}
],
|
Neat! I also want to highlight in-toto/attestation#212 |
@adityasaky you read my mind! Glad to see the adoption of resource Descriptors in the subject too. Will adopt it! |
@adityasaky I am currently using these exported structs to model my in-toto attestations https://github.com/in-toto/in-toto-golang/blob/c46e06390c231e197b91de72659ff0d1bd5dd3e1/in_toto/attestations.go#L31 I can see that in the PR you pasted you actually update a I can't find an updated in-toto statement + subject, should I expect them to be released in in-toto-golang? Note: I am currently loading the resource descriptor from here but my issue now is from where to get an updated in-toto statement which uses the new subject schema. Thanks! |
Updated bindings were autogenerated here: in-toto/attestation#219 That said, these aren't available as a release just yet. The attestation maintainers are working on stabilizing how the bindings are generated and maintained for different languages. |
FWIW, we want to move in-toto-golang to using provenance/statement/resource descriptor from in-toto/attestation as well in the coming weeks. |
I love living on the edge! :) So it seems that eventually I should move away from using |
That makes sense. Would you recommend me to wait until you stabilize the protoc generation or would you say that's fairly safe to do some work on top of |
I'll defer to @TomHennen, @marcelamelara on that one. |
Exciting to see this adoption! For in-toto Golang, I expect that the Golang bindings will be much more stable post in-toto/attestation#212 . That said, I'm currently working on some wrapper APIs that do some validation and testing per the spec, so if you don't want to have to re-implement that, I'd probably still wait. Hoping I can get that PR out in the next couple weeks. |
@marcelamelara thanks for the context and for the work you are doing on in-toto! I'll wait then and revisit this issue in a couple of weeks, let me know if there is anything I could do to help :) Thanks! |
@migmartri I got this PR out sooner than expected: in-toto/attestation#220 Would be great if you could provide any feedback! |
@marcelamelara thanks for working on this and letting me know, that was fast! Just added a comment! https://github.com/in-toto/attestation/pull/220/files#r1192475597 |
In-toto 1.0 has been released 🎉 and it includes a couple of major enhancements that seem relevant to the Chainloop project.
New upstream predicates and guidelines available
Chainloop uses a custom predicate
chainloop.dev/attestation/v0.1
. We should re-evaluate the need of our custom predicate or use an existing one. If we still do, we should make sure it adheres to the guidelines and if it would make sense to try to upstream it.Attestation bundle
The new attestation bundle can be specially handy in the context of #53. It will allow us to bundle not only the Chainloop generated DSSE envelope but any other generated envelope.
For extensibility in the future, it might be a good idea to default to a bundle for communication with the control-plane
Resource descriptor
Currently Chainloop encodes the materials in the attestation like this. It's basically an extension of a slsa material (with digest and URI) plus some additional metadata used by the Chainloop controlplane for validation and routing (name and type)
The new resource descriptor might be a good fit to replace that custom type. The
annotations
field could contain the custom chainloop types.Congrats @adityasaky, @TomHennen and rest of the team for the release!
Feel free to drop any thoughts or comments, always appreciated!
TODO
The text was updated successfully, but these errors were encountered: