3 ms·
For reproducible builds the source needs to be available to the users, so they can rebuild the software themselves and verify the binary that is being distribut
by m4rtink 7y ago
For reproducible builds the source needs to be available to the users, so they can rebuild the software themselves and verify the binary that is being distributed is 1:1 similar.
There is really no way around that.
As for "messing it up on developer machine" - that's not really possibly if the build is really reproducible. If the users get the same binary after building the source, they can be sure they have the source matching the binary.
If the binary they get is different from what the developer built on their machine, there is a good chance they don't have the source matching the binary, which is exactly what reproducible builds aims to protect them from.
- jka 7y agoYes - to clarify this further: as I understand it (and I'm not deeply familiar with the process), reproducible builds require that developers take additional measures to ensure that their source code cannot accidentally or intentionally produce variant build output. That means that some commonly-used practices like embedding current timestamps into files become unacceptable. It does tighten the development constraints -- although frankly, that's similar to many other secure coding practices. Better tooling, linting and frameworks will help to reduce the developer friction.
- m4rtink 7y agoYep, IIRC timestamps are one of the issues - you can either drop the.timestamp or inject a well documented timestamp from the outside, so the user can do that as weel during the rebuild. Indeed, a lot of the stuff you need to do to achieve reproducible builds can definitely make your build process more robust and secire.
- AlphaSite 7y agoI think on iOS with bitcode it would need changes within Apple to make some form of secure supply Han possible.