Hi Emmanuel, On 15.05.2026 16:22, Emmanuel Bourg wrote: > Reproduciblity should be confirmed at release time, everyone voting > could report the hashes of the artifacts built. Or it could be verified > continuously, on each code change, by an automated process.
I agree. The open question for me is how third-party users verify, after the fact, that we actually followed such a procedure. That's where build provenance attestations come in: each voter's rebuild can be recorded as its own attestation, and a consumer can check that the artifact they downloaded was independently confirmed by multiple committers. Ideally we'd append voter attestations to the `*.intoto.jsonl` artifact that the release manager stages during the vote. As far as I know that isn't currently possible with Maven Central, but as a first step we could publish the set of voter attestations alongside the source distribution archive. >> 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. > > Without actual use case this all looks like a lot of paperwork for > little benefit. I suggest keeping an eye on this standard while fixing > the reproducibility issues in our builds. Sorry, I was ambiguous in my previous reply. There are actually two distinct use cases, and only one of them is hypothetical: 1. Policy-based verification (working today). Adolfo and I have a toolchain that lets consumers verify our attestations against a shared policy. We can publish the policy from an independent repository (`commons-parent` is one candidate) and refine the checks over time. Today the policy is minimal: it confirms that a build provenance attestation exists and that it's signed by one of a known set of GPG keys. A user could do this manually, but a shared policy automates it and gives us a central place to tighten the rules as the ecosystem matures. 2. Attestation-driven rebuilds (not yet possible). Using the attestation as input to a workflow that reproduces the artifact. This is, I think, the use case you had in mind. We don't have tooling for it yet. > For the build environment I had more the compiler and build tools in > mind than the time settings. In Debian timezone independence is required > for a build to be flagged as reproducible. That makes sense and I think we should adopt the same bar. As far as I know, our only source of timezone dependence is the Moditect plugin and the way it updates the local MS-DOS timestamps in ZIP archives. I'll take a look at fixing that. Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
