I haven t dove deep into that new | Dagger | Page 1

frank harbor Dec 2, 2022, 5:45 PM

#

Thanks Erik, I'll try and take a look at how Dagger uses it and figure out if Dagger can do the attestation..

somber mason Dec 2, 2022, 5:53 PM

#

Awesome, let me know what you find. My starting point would have been to see if the attestations get included as part of Build responses, e.g. the return val of the call here: https://github.com/sipsma/dagger/blob/ec51da155e85ecda92ba6c14812d567f37269f8a/engine/engine.go#L137-L137

But they may have implemented differently or left that out for now, so just a starting place to look maybe

frank harbor Dec 2, 2022, 6:07 PM

#

Looks like it's not the return value but it does require a flag to be set as input

#

Ah, test file gives away a lot https://github.com/tonistiigi/buildkit/blob/fb917b9ec9527706ea6691f8332d37d8f65c4d93/frontend/dockerfile/dockerfile_provenance_test.go#L60

#

If only I knew what Solve did and how it is different from Build 😅

#

From what I can tell, Dagger would need to pass that FrontendAttrs{ "attest:provenance": " provReq = "mode=max"}

And the resulting OCI artifact would be attested.

From the PR description and code, it seems like there are times where we would need to pass in the vcs:source
too.

#

So in Dagger world, VCS would only be applied when people have reference a "Git layer" , right? As in if the DAG has a git layer in it, all the subsequent buildkit calls need to have pass in the vcs:source attribute?

somber mason Dec 5, 2022, 8:19 PM

#

frank harbor If only I knew what `Solve` did and how it is different from `Build` 😅

It's extremely confusing. You can think of Build as the "outer" call that opens up a session between the client and buildkitd. Then within Build you can issue multiple Solve calls that run on that session.

From what I can tell, Dagger would need to pass that FrontendAttrs{ "attest:provenance": " provReq = "mode=max"}
Just did another pass through and yep that looks correct.

So in Dagger world, VCS would only be applied when people have reference a "Git layer" , right? As in if the DAG has a git layer in it, all the subsequent buildkit calls need to have pass in the vcs:source attribute?
This I'm still not sure about yet, looking through the code hasn't been super enlightening. The only place I saw this used is:

Here, where it gets read: https://github.com/sipsma/buildkit/blob/9624ab4710dd1a63453cc028802c9992b9715f3c/solver/llbsolver/provenance/predicate.go#L166-L166
And then later in the same function here, where it just gets passed through to the final attestation: https://github.com/sipsma/buildkit/blob/9624ab4710dd1a63453cc028802c9992b9715f3c/solver/llbsolver/provenance/predicate.go#L225-L225

So from that it just seems like metadata that gets passed through, not anything buildkit specifically processes really right now. What I don't understand is what's supposed to happen if there's multiple Git refs inside the DAG.

I'm wondering if it's meant to be the VCS of buildkit itself (or of the code for the frontend being used)? Would need to investigate more

frank harbor Dec 5, 2022, 8:27 PM

#

Couple more references in Dockerfile frontend https://sourcegraph.com/github.com/sipsma/buildkit@9624ab4710dd1a63453cc028802c9992b9715f3c/-/blob/solver/llbsolver/provenance/predicate.go?L225%3A32=#tab=references

predicate.go?L225:32

#

I could be way off but in one of the test case it looks like that metadata is passed as a label in the attestation.

#

So it's probably just there for people to know that a git repo is associated with the build? I don't know why it would be there, tbh.

#I haven t dove deep into that new