Hi Emmanuel, On 5.05.2026 13:38, Emmanuel Bourg wrote: > Le 05/05/2026 à 12:21, Piotr P. Karwasz a écrit : > >> On 5.05.2026 11:57, Emmanuel Bourg wrote: >> - A reproducible build can still be malicious or come from an >> unauthorized source. > > A reproducible build provides a proof that a binary comes from a given > source. Who/where/when the source was built doesn't matter once the > build is reproducible. This assumes the source is trusted of course.
Agreed that once a build is reproducible, the identity of the builder no longer matters for trust in the binary itself. But SLSA Provenance still has value even for reproducible builds: 1. Reproducibility is a property you confirm after the fact, by rebuilding. SLSA Provenance lets a consumer make a trust decision *before* spending the cost of a rebuild, based on who built the artifact and how. 2. Two independent SLSA Provenance attestations for the same artifact are themselves evidence of reproducibility. Draft versions of SLSA introduce a `SLSA_BUILD_REPRODUCED` property on verification summaries, which is set when more than one independently operated build platform attests to the same output: https://slsa.dev/spec/draft/verified-properties >> - A build can of course be not reproducible, in which case we need to >> trust the builder. In our case the SPDX artifact is not reproducible. > > If our builds aren't reproducible yet I think we must aim to make them so. > > What is the issue with the SPDX artifact? Historically the SPDX Maven plugin has had several reproducibility issues: https://github.com/spdx/spdx-maven-plugin/issues?q=is%3Aissue%20state%3Aclosed%20reproducible These all appear to be closed now, but I don't recall ever successfully reproducing an SPDX SBOM in practice. It's also possible the plugin still depends on hard-to-spot environment values, such as the absolute project path. I'll try to debug this during the next vote. >> In the attestation produced by `build-attestation` I tried to capture >> the information that we see in each vote e-mail, so they could >> constitute a machine-readable version of the e-mail. > > Is there a machine that already do something useful out of this > attestation? Not yet, beyond verification of the SLSA attestation itself. But once builds start shipping with these attestations, it should be straightforward to build a workflow that consumes the attestation and reproduces the artifact automatically. >> The information contained also helps reproducing the artifacts, by >> capturing the environment characteristics (such as JDK version, >> time-zone and Maven version) that we know can influence the build. > > Capturing the build environment is a good idea, but I'd rather fix the > reproducibility issue caused by the timezone than documenting the > timezone used at build time. I'd draw the distinction slightly differently. Depending on the timezone doesn't make an artifact non-reproducible; it just makes it harder to reproduce. By definition, an artifact is reproducible if it can be rebuilt on a machine with *exactly* the same environment. Reducing the number of environment variables that matter is valuable because it widens the set of machines that can reproduce the build, but it isn't a precondition for reproducibility. So the two efforts complement each other. Documenting environment characteristics today lets anyone with a matching setup verify the build. Reducing environmental sensitivity over time lowers the bar for who can verify it. And consumers who can't match the environment at all can still rely on SLSA attestations issued by people who can. Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
