Le 05/05/2026 à 12:21, Piotr P. Karwasz a écrit :
On 5.05.2026 11:57, Emmanuel Bourg wrote:
This all looks quite burdensome. Isn't provenance attestation irrelevant
if our builds are reproducible anyway?
Provenance and reproducibility cover overlapping, but similar problems:
- 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.
- 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?
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?
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.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
