3 ms·

Yeah, thinking about just a bit more, it seems like it's not possible to do without giving the source to Apple. If it's done on a the developer's machine I'm gu

Yeah, thinking about just a bit more, it seems like it's not possible to do without giving the source to Apple. If it's done on a the developer's machine I'm guessing it's always going to be possible to mess with it somehow.

m4rtink 6y 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 6y ago
  Yes - 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 6y ago
    Yep, 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 6y ago
  I think on iOS with bitcode it would need changes within Apple to make some form of secure supply Han possible.

m4rtink 6y 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 6y ago
Yes - 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 6y ago
  Yep, 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 6y ago
I think on iOS with bitcode it would need changes within Apple to make some form of secure supply Han possible.