docs: explain attestation-inline=false

[AkihiroSuda]

This option is expected to be used as a workaround for compatibility issue with third party registry implementations that do not properly implement the OCI Distribution Spec.

It is reported that GitLab Container Registry needs this.
moby/moby#28394 (comment)
( Thanks to @slonopotamus )

[slonopotamus]

Thanks again! I would probably reword the text to be more specific, so it would explain that this option disables wrapping image manifest with index manifest (unless there are other reasons for manifest to exist, like multi-arch image, I suppose?)

[tonistiigi]

Why not just not set the attestation if you don't want it added?

[AkihiroSuda]

Why not just not set the attestation if you don't want it added?

The attestation seems added by default now

[tonistiigi]

@AkihiroSuda Not in buildkit. And you can still disable the the attestation directly, eg. --provenance=false in buildx .

[jedevc]

Hm, @tonistiigi and @crazy-max... do you have any memory for why we added attestation-inline in the first place?

It was added in #3466, and it looks like I had the idea to kill it in #3420. I can't quite work out where it's used. We seem to need it as an internal-only concept, so that it's opt-in for local/tar exporters, but opt out for the image exporter, which is exposed as the inline-only option used by buildx: https://github.com/docker/buildx/blob/cec4496d3be405cf462dc1d1490fc4a97b6136f9/build/build.go#L270

But I'm not sure why attestation-inline exists, or why we put it in. Maybe we should just remove it, since --provenance=false is a much better alternative (and I can't see anyone using it, including us).

---

The logic in #3466 also seems faulty to me - I'm not quite sure why we chose different logic for the oci exporter, I think we should have it behave identically to the image exporter, and always produce provenance - having separate behavior is confusing (maybe we did this just to be safe and try and avoid as much breakage as possible).

I think we could change this behavior in the upcoming release, unless there's a good reason not to.

---

small rant (hindsight is 20/20). inline is such a weird name for this behavior, it's nothing about inline attestations, it's more about a tag that different exporters can use to detect if an attestation should be included by default.

Kinda can't change that now (backwards compat 🎉), but I think we might have the opportunity to revisit how this works now that #4134 is ready - there's the use case that a user might want different attestations for each exporter, and I think a solution to that might also cover #3458 (which I'm interested in for adding better attestations support to Dagger). I might take a look at this in the next couple weeks 😄

[slonopotamus]

So, do you suggest that #3466 is reverted (not technically, but logically) so that image exporter behaves the same way as oci/docker? WRT backward-compatibility part - just name it image2 exporter or whatever) And deprecate image one.

[tonistiigi]

The logic in #3466 also seems faulty to me - I'm not quite sure why we chose different logic for the oci exporter, I think we should have it behave identically to the image exporter, and always produce provenance

I think it was to not break docker buildx build -o type=oci . | docker load .