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

in-toto 1.0 support #60

Closed
1 of 3 tasks
migmartri opened this issue Apr 3, 2023 · 13 comments · Fixed by #397
Closed
1 of 3 tasks

in-toto 1.0 support #60

migmartri opened this issue Apr 3, 2023 · 13 comments · Fixed by #397
Assignees
Labels
enhancement New feature or request

Comments

@migmartri
Copy link
Member

migmartri commented Apr 3, 2023

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.

 "materials": [
      {
        "material": {
          "slsa": {
            "digest": {
              "sha256": "7e5f829611edeedf36a7318f78e6914b85a8e2f90ac8628cc868b2e87204d93b"
            },
            "uri": "ghcr.io/chainloop-dev/frontend"
          }
        },
        "name": "frontend",
        "type": "CONTAINER_IMAGE"
      },
      {
        "material": {
          "slsa": {
            "digest": {
              "sha256": "092252ea069679c658a949748ca0bee9405d36630d6b460964c7225708de0bb5"
            },
            "uri": "sbom.cyclonedx.json"
          }
        },
        "name": "frontend-sbom",
        "type": "SBOM_CYCLONEDX_JSON"
      }
    ],

Congrats @adityasaky, @TomHennen and rest of the team for the release!

Feel free to drop any thoughts or comments, always appreciated!

TODO

  • Look into attestation bundles
  • Resource descriptors in predicate materials
  • Resource descriptors as subject items
@migmartri
Copy link
Member Author

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"
         }
      ],

@adityasaky
Copy link

Neat! I also want to highlight in-toto/attestation#212

@migmartri
Copy link
Member Author

@adityasaky you read my mind! Glad to see the adoption of resource Descriptors in the subject too. Will adopt it!

@migmartri
Copy link
Member Author

@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 proto file, are you generating the Go bindings anywhere?

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!

@adityasaky
Copy link

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.

@adityasaky
Copy link

FWIW, we want to move in-toto-golang to using provenance/statement/resource descriptor from in-toto/attestation as well in the coming weeks.

@migmartri
Copy link
Member Author

Updated bindings were autogenerated here: in-toto/attestation#219

I love living on the edge! :)

image

So it seems that eventually I should move away from using in-toto-golang model package and use the autogenerated bindings in the attestation repo correct?

@migmartri
Copy link
Member Author

migmartri commented May 9, 2023

FWIW, we want to move in-toto-golang to using provenance/statement/resource descriptor from in-toto/attestation as well in the coming weeks.

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 https://github.com/in-toto/attestation/tree/main/go/v1, granted fixing the library import to a specific commit?

@adityasaky
Copy link

I'll defer to @TomHennen, @marcelamelara on that one.

@marcelamelara
Copy link

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.

@migmartri
Copy link
Member Author

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!

@marcelamelara
Copy link

@migmartri I got this PR out sooner than expected: in-toto/attestation#220

Would be great if you could provide any feedback!

@migmartri
Copy link
Member Author

@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

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

Successfully merging a pull request may close this issue.

3 participants