Buildkit attestation

[violet lynx]

I'm curious if its possible to inline Buildkits in-toto attestation into an image which is built with Dagger? (See here https://github.com/moby/buildkit/blob/master/docs/attestations/README.md)
As far as I can see currently the images are not exported with SBOM/Provenance attestation... Is there a known workaround how to enable it?

[ancient elbow]

Hey @violet lynx, yeah we have not added support for that yet, but it's something we are interested in. I created an issue w/ the feature request here: https://github.com/dagger/dagger/issues/5621

Until we've added support, there's not really any workaround unfortunately

[mortal abyss]

I've use buildkit and replaced it with Dagger and now realized there's no support for SBOM, is this at least on a roadmap? I might try to update the dagger engine to expose the buildkit functionality ( --opt attest:sbom=)

[zenith moss]

I'm definitely interested in this as well (since I implemented the original functionality for SBOMs in buildkit) 🎉
I think we're probably going to want to take a slightly different approach for SBOMs in dagger, though it would be awesome to integrate with upstream buildkit support as well.

Out of curiosity @mortal abyss, how are you using the SBOMs? Do you consume the SBOMs directly off of the images that are pushed? Or do you export them locally, and then handle them from there?

It probably wouldn't be too much work to add a stopgap solution for SBOMs and Provenance attestations by updating the Export /Publish functions to allow taking those attestation arguments as a helper for those migrating from buildkit directly - but we definitely want something richer over time, that allows you to take a provenance/sbom at any point in your pipeline and export to wherever you want, not just a registry. @ancient elbow any thoughts on whether something like that we could use as a reasonable stop-gap while we consider the long-term design? (I know we have Experimental prefixed args for some of these things)

[violet lynx]

Sounds good. it would love to see when Dagger offers something like Tekton Chains in future
https://opensource.googleblog.com/2023/03/getting-to-slsa-level-2-with-tekton-and-tekton-chains.html I don't not many companies which are using Tekton. But almost all of them choose tekton because of the attestation capabilities

[zinc tide]

👋Hi everyone! I'm really interested in having this feature available and happy to contribute to the best of my abilities. I've started a draft PR (https://github.com/dagger/dagger/pull/6129) where the ContainerPublishOpts is extended to pass an array of attestations (SBOM and provenance).

How can I generate the new Go SDK client? I tried extending the core/schema/container.graphqls file and running go run . --lang go --output ../../sdk/go/ in ./cmd/codegen but the ./sdk/go/dagger.gen.go doesn't contain the new attestation type field.

[hazy dust]

I guess the proper way would be to do a bit of bikeshedding to understand what's the best UX for Dagger to adopt. Probably @zenith moss and @ancient elbow have some good ideas around this

[zenith moss]

Hey hey 😄 so sorry for the delay on this - I'm gonna try and dive into this later this week 🎉 (now I'm back from vacation 🌴)
Thinking about this a bit more, I'm not entirely sure about the approach of attaching attestations into produced images as the default - it feels much more likely that users will want to generate attestations for exports, and then handle them themselves (though we should also allow attaching them!). This would enable more complex workflows like, output my docker image as an oci tarball, generate an attestation for that tarball, and then upload both to github releases. This is a guess though, curious what other people in this thread think.

So it feels like we're going to definitely want to do some bikeshedding here, I'll throw together a proposal ASAP that we can try and work out. There's going to be some collision with some other things that we should straighten out in attestations land: we should bump in-toto/SLSA versions, there's a bunch more logic to interact with to do with multiple exporters, and just general cleanup I'd like to do (https://github.com/moby/buildkit/pull/4435#issuecomment-1830109768). Attestations also aren't complete without signing, so we might need to add that as well 😢 I expect we'll need a fair number of buildkit changes.

There's also the dimension of how this should interact with modules - people seem to have gravitated in a couple places to writing SBOM modules. I think that's the right way to go with SBOMs, instead of using the approach in https://github.com/docker/buildkit-syft-scanner (disclaimer: i built that) - it wouldn't be hard to allow using the buildkit-syft-scanner if we have SBOM modules.

I think I'd like to avoid just adding the options to the exporter right away without having a rough idea of what dagger's approach to attestations should be - even if a good temporary drop-in is to just do what buildkit does.

[zenith moss]

r.e. this specific question, you can re-gen the go sdk client with ./hack/make sdk:go:generate from the root of the repo.

[zenith moss]

realized we should probably write this down somewhere 😄 https://github.com/dagger/dagger/pull/6173

[zenith moss]

sorry for my slowness (i got distracted, and then got sick): but i wrote up a proposal for what we could do in dagger for attestations 🎉
https://github.com/dagger/dagger/issues/5621#issuecomment-1852318694