Default image output from buildx v0.10 prevents some third party sbom tools from working.

[34fathombelow]

This issue should be considered as constructive criticism. I know a lot of hard work has gone into the provenance feature. I do believe we are headed in the right direction, however I have listed a few reasons below why this new feature should be disabled by default and be strictly opt in.

1. By default in buildx v0.10 a provenance is generated and uploaded to a registry. These new manifest/artifacts are causing issues with third party sbom tools. Such as https://github.com/kubernetes-sigs/bom, which throws an error due to the unknown/unknown manifest that it does not recognize.

2. Uploading artifacts to a users registry without prior notice and by default seems very intrusive.

3. This new feature is not compatible with a number of known registries, and has to be disabled manually.

4. The documentation should point out the SLSA level (SLSA 1) of the provenance generated. Generating a provenance is not about just checking a box. This may lead people to believe they are following proper supply chain security, when infact it's just a minimal implementation.

Thanks for all the hard work that's put into buildx, it's an awesome and powerful tool.

[tonistiigi]

Move to #1533 for tracking

This new feature is not compatible with a number of known registries, and has to be disabled manually.

We generate a valid OCI image and not using any features that were not in the very initial spec. In predecessor Docker formats the same concept existed earlier. There have been a lot of years since these standards were defined. Sooner or later, we need to finally start to use them.

Uploading artifacts to a users registry without prior notice and by default seems very intrusive.

Build has always collected some level of this information, for example in the History array in image config or Buildinfo for tracking dependency versions that the new provenance replaces. We have improved the current support and moved to industry-defined formats. We have made sure that by default we don't leak unexpected things like build-args (although some may be in history array already), source code for build steps etc. These properties are opt-in for the user to allow for their builds.