3 ms·
This kind of attestation doesn’t realistically add any value. It just lets downstream users assert that the build happened on a host managed by Microsoft. That
by WhyNotHugo 1y ago
This kind of attestation doesn’t realistically add any value. It just lets downstream users assert that the build happened on a host managed by Microsoft. That doesn’t reflect anything with regards to the package content itself — although it may allow ticking some compliance checkbox somewhere.
Reproducible builds are a lot more valuable. They let downstream consumers verify that the package was actually generated with the documented sources and inputs.
- scheme271 1y agoHaving both is really where things are at. That way you can verify that the tools being used for the build aren't doing something behind your back and that the code that you see is what you're getting.
- WhyNotHugo 1y agoGitHub actions encourages using mutable references for “workflows”, so the inputs used during the build process can change before and after the build. That seems like an obvious vector for doing something behind your back.
- _flux 1y agoAssuming you trust GitHub CI, why doesn't attestation bring the same value? I haven't really looked into what it entails in establishing an attestation for a CI-built package, though, but I thought the idea was that you will at least get a git commit id that will describe the work, and that the attestation says that that's the work that's been done? Reproducible building would be useful for removing the need to trust GitHub. But then what do you need the builds for anyway, you would always need to build it yourself anyway?