Hi Piotr, Thanks for your feedback - few things inline ...
On Wed, 18 Mar 2026 at 21:53, Piotr P. Karwasz <[email protected]> wrote: > However, I > think that with the current state of the art, we have reached something > of a paradox. > > At present, we tend to prefer releases built on committer-owned machines > over those produced by GitHub Actions, even though: > > - GitHub Actions builds run in clean, ephemeral environments (Docker > images), > > - while committer-owned machines may contain residual artifacts from > previous builds and dirty cached dependencies. > > From this perspective, CI-based builds can in practice offer a more > controlled and reproducible environment than local builds. This! And for example the bit on the SLSA site about build isolation strength. There may be as much of an argument that only reproducible builds should be allowed on committer-owned machines. As someone who has code-signed numerous releases locally, the only guarantee that they are what they say they are is my signature as release manager, and the hope that my machines are correctly configured and I've not made any mistakes. :-) At least the CI offers another more detailed trail that the PMC can validate against. > In the case of NetBeans, I believe one way to address the trust concerns > would be to generate SLSA build attestations as part of the CI process. > The Release Manager could then verify these attestations prior to > initiating a release vote. The SLSA specification already defines a > verification procedure for this purpose: I was vaguely aware of SLSA, but hadn't really considered for this purpose (ie. provenance for voting purposes). Generating these might offer a more useful format for this rather than relying on the whole log. Although I don't know if it would include anything not already output? The log contains other build information that would be useful to persist anyway. Do we have ASF examples / a process for signing SLSA provenance file(s) during the run, independently of the release manager doing so afterwards? I would expect the link to the particular build run to be included in the vote email - everyone voting should then be able to verify any attached attestations, logs, etc. completely independently of the RM. This actually also raises another thought. We used to vote on installers as part of our main release vote. My current workflow builds from the released binary zip after the release vote. For a useful provenance here, we might need to have a two-step voting process, or we might need a permalink for input binaries that persists through voting, release and archiving. Thanks and best wishes, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
