5 ms·

This is again one of those cases where, even though it's nice to see the source code, it's very hard to verify what's actually running on our devices. The same

This is again one of those cases where, even though it's nice to see the source code, it's very hard to verify what's actually running on our devices. The same case with Signal and other secure messaging apps. How would a scheme work, that (within the confines of the current App Store regime) allowed users to verify the source code look? Could Apple/Google maybe hash every file as part of the compilation/linking process, and then concatenate that in some way and include it in the signed binary and expose it in the App Store? It would be really neat with some process where I can clone a repo on my machine, run some script and get an identifier, and verify that it is the same as what is being shown in the App Store on my device.

m4rtink 6y ago
There are initiatives to provide reproducibke builds - you build the code youself and get a binary identical to the one being distributed. This is mainly taking place in Linux distros at the moment, bit Fdroid is doing something related on Android, building all the apps they host on their own infrastructure.
- filleokus 6y ago
  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.
emdowling 6y ago
It’s pretty simple to reverse engineer an Android binary. While most Android apps ship with code obfuscation, it’s relatively easy to get around. Using that method, one could determine if the publicly available app came from the same source code (it would at least allow you to determine no extra nasty bits had been added). iOS is a little harder. If you have the dsym files it’s pretty trivial to the same exercise as Android. NHSX could choose to release them so people could again verify it more or less matches.
- g_p 6y ago
  There's no obfuscation that I could see on the Android app, which should help with this. Certainly when looking across to the source release, it was a familiar codebase (modulo the fact the reversed version was in pseudo-java, and the original codebase is in Kotlin).
- saagarjha 6y ago
  dSYM files are not very useful in ensuring reproducible builds; what you actually need is a jailbroken device and hashes of certain binary segments that Apple doesn't touch too much.
innomatics 6y ago
If they had a transparent build server which published directly to the stores (ala fastlane) that would go a long way. Folks could see builds running when code is pushed and the app versions being released soon after.

m4rtink 6y ago

There are initiatives to provide reproducibke builds - you build the code youself and get a binary identical to the one being distributed. This is mainly taking place in Linux distros at the moment, bit Fdroid is doing something related on Android, building all the apps they host on their own infrastructure.

filleokus 6y ago
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.

emdowling 6y ago

It’s pretty simple to reverse engineer an Android binary. While most Android apps ship with code obfuscation, it’s relatively easy to get around. Using that method, one could determine if the publicly available app came from the same source code (it would at least allow you to determine no extra nasty bits had been added). iOS is a little harder. If you have the dsym files it’s pretty trivial to the same exercise as Android. NHSX could choose to release them so people could again verify it more or less matches.

g_p 6y ago
There's no obfuscation that I could see on the Android app, which should help with this. Certainly when looking across to the source release, it was a familiar codebase (modulo the fact the reversed version was in pseudo-java, and the original codebase is in Kotlin).
saagarjha 6y ago
dSYM files are not very useful in ensuring reproducible builds; what you actually need is a jailbroken device and hashes of certain binary segments that Apple doesn't touch too much.

innomatics 6y ago

If they had a transparent build server which published directly to the stores (ala fastlane) that would go a long way. Folks could see builds running when code is pushed and the app versions being released soon after.