Fixes provenance always enabled

[suwakei]

Problem:

Currently, the build option Provenance is hard-coded to true in the runBuild function.

// cmd/compose/build.go L170-L171funcrunBuild(...) {
// ...apiBuildOptions, err:=opts.toAPIBuildOptions(services)
apiBuildOptions.Provenance=true// Here's the problem.// ...
}

This prevents users from disabling the generation of SLSA provenance metadata(used for software supply chain security and build traceability) at build time.

Since the provenance flag already exists in the buildOptions structure, this hard-coded value should be removed, and users should be able to control it via a command-line flag.

Suggestion for improvement:

Add --provenance flag

Introduce a new --provenance flag to the build command. This will give users explicit control over whether provenance metadata should be generated, making the tool more flexible and intuitive.

As a security best practice, the default value of this flag should be true with true as the default, so provenance is generated unless users explicitly disable it.

Benefits

Improved control: Users can disable provenance generation by specifying --provenance=false.

Code clarity: Removes hard-coding and delegates control to existing buildOptions structure.

Security best practice: Enabling provenance by default supports secure software supply chains.

[glours]

👍 LGTM
For legal reasons you need to sing-off your commits

[glours]

Ho and you will need to run make docs to update the doc files

[ndeloof]

this is somehow contradictory with #12853

Also, usage of this option is a bit obscure to me, as setting this to false enables provenance attestation: https://github.com/docker/compose/blob/main/pkg/compose/build.go#L474-L476

[ndeloof]

This also makes me wonder we don't have attestation (or provenance?) attribute in the compose-spec

[ndeloof]

.. also need to check we correctly behave when BUILDX_NO_DEFAULT_ATTESTATIONS is set

[glours]

Good catches @ndeloof, my bad, my review was too fast 🤦‍♂️

[ndeloof]

Not strictly speaking a solution to this issue, but I created compose-spec/compose-go#809 to offer better control over attestation generation.

[suwakei]

@ndeloof@glours
Thank you for the ongoing work on this!
I see that #13067 offers a more comprehensive solution by updating the compose-spec and aligning with the attestations documentation.

Since that PR supersedes this one and addresses the same goal in a more extensible way,
I intend to go ahead and close this PR, and I’d be happy to contribute to #13067 if that’s helpful.

Happy to review or help refine anything there.
Really appreciate the feedback and learning opportunity — it’s been very helpful!

[ndeloof]

Closing as #13067 was merged