Hi Jarek, On 21.03.2026 13:28, Jarek Potiuk wrote: > I think attestations provided with a remote, inaccessible (by the release > manager) build system inherently differ from reproducible builds and > protect against a bit different scenarios. One thing they do indeed - they > do prevent the risk from a rogue release manager. But they also shift trust > to GH making it more difficult to trace the sources of compromise when > external attackers breach them - or even to know that a breach occurred. > The latter point is crucial: if your GH runner is compromised, you will > only find out after the release. If the machine used by the release manager > is compromised and you have reproducible builds, you will know before the > release. I think for me the last point is really important, and it's the > reason why dropping reproducible builds and switching to GH makes it a bit > more dangerous. > > GH actions do not provide the same level of security or address exactly the > same risk as reproducibility, mostly because compromising the single system > that provides attestations invalidates the attestation for that build. > Reproducibility addresses this by requiring you to compromise few such > systems - potentially largely independent ones—which makes it exponentially > harder to pull of - unless you are able to hack-in the tools (IDEs, AI CLIS > etc.) that multiple people are likely to use (and remote build system > doesn't need).
SLSA attestations do *not* protect against a rogue release manager and the Trivy incident illustrates this well. The malicious v0.69.4 release was almost certainly published alongside SLSA build attestations, because the attacker had full access to the same CI credentials that generate them. I couldn't locate the attestation payloads themselves, but there are Rekor entries corresponding to the malicious Docker images. You can find them using the artifact checksums published here: https://www.docker.com/blog/trivy-supply-chain-compromise-what-docker-hub-users-should-know/ The *presence* of an attestation doesn't mean a release is legitimate. What it does give you is richer information about the release process, and that's where I think attestations and reproducible builds are complementary rather than alternatives: - Reproducible builds let you verify that *output* artifacts are identical bit-for-bit, but tell you nothing about inputs or build environment. - SLSA attestations also record hashes of *input* artifacts and build environment metadata. This means: - If outputs are *reproducible* but you can't reproduce them locally, the environment data can help you diagnose why. - If outputs are *not* reproducible, but you trust the build process, you can at least verify that the inputs were correct. For NetBeans, reproducible output artifacts remain the ideal. But when that isn't achievable, I'd argue that a simple, well-reviewed GitHub Actions workflow, combined with a script that lets the release manager verify the *input* artifacts, should provide enough security to release “convenience” (hence unofficial) binaries. Such workflow, of course should be minimal, with no caches and validate the checksum of each downloaded resource. Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
