Split attestation crafting steps

[zmarouf]

It's currently not possible to push an existing annotation to Chainloop without crafting one via Chainloop. The desired behavior would be to allow users to push their own attestations (e.g generated via cosign) to Chainloop to leverage the workflow contract verification flow.

Extra work might be needed to extend the predicate definition in the contract schema.

[migmartri]

Thanks @zmarouf for reporting this.

This is a very interesting use-case. But first, I'd like to elaborate the technical context for public knowledge transfer.

Unsolicited Context :)

chainloop attestation push indeed takes the temporary attestation state which contains all the information about the added materials, env information and so on and

• 1. Validates that the intermediate state contains all the required information stated in the contract https://github.com/chainloop-dev/chainloop/blob/625cefa539018739d2d2f40cf77f5416c7e35014/app/cli/internal/action/attestation_push.go#L61
• 2. renders a custom in-toto predicate https://github.com/chainloop-dev/chainloop/blob/625cefa539018739d2d2f40cf77f5416c7e35014/internal/attestation/renderer/chainloop.go#L40
• 3. Adds it to an in-toto statement https://github.com/chainloop-dev/chainloop/blob/625cefa539018739d2d2f40cf77f5416c7e35014/internal/attestation/renderer/renderer.go#L99
• 4. wraps it into a signed DSSE envelope https://github.com/chainloop-dev/chainloop/blob/625cefa539018739d2d2f40cf77f5416c7e35014/internal/attestation/renderer/renderer.go#L84
• 5. pushes it to the control plane https://github.com/chainloop-dev/chainloop/blob/625cefa539018739d2d2f40cf77f5416c7e35014/app/cli/internal/action/attestation_push.go#L87

From the pure technical point of view I can definitely see couplement during the push process, since well, as stated not only pushes but also, validates, renders and signs.

Technical changes

My understanding is that in order to achieve pushing any kind of already generated dsse-envelope or in-toto attestation we'd need to update the client side code to

1 - Skip 2,3 and 4 if you provide an attestation yourself and 2 - Move the validation process at the end right before the push.

The reason for moving the validation is that to me, validating that such attestation and its content is expected as defined in a workflow contract. Could you confirm that would be the desired behavior for you too @zmarouf?

Top of mind technical challenges

There are some challenges involved in providing non-chainloop attestation predicates and this is that chainloop predicates contains enough metadata to a) the name of the artifact b) the artifact kind (i.e SPDX_SBOM, ARTIFACT, CONTAINER_IMAGE) and

a) is being used by the contract validation to match material requirements with the actual attestation. b) on the other hand is being used for kind validations and fan-out integration routing, so for example if you have attached a dependency-track SBOM integration, only SBOM artifact kinds will be sent.

If as part of this feature we still want to leverage contract validation and third-party fan-out we need to figure out how to annotate, wrap, something, to identify the content of the custom attestation predicate.

An alternative to that would be to, in the case of cosign, detect one of the supported kinds and use that as context. I.e if you provide a cosign SBOM predicate type, infer the kind from there. We'll still need to figure out something about the naming.

@zmarouf a) do you have an example of the kind of attestations you'd like to provide to chainloop and b) do you also want to leverage third party integration routing?

Thank you!