Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



Assuming 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?


Having 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.


GitHub 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: