3 ms·

Is there any information on the guaranties Moxie Marlinspike/Whisper Systems provide on the Apps downloaded from the App-Store? I get that their source is open

Is there any information on the guaranties Moxie Marlinspike/Whisper Systems provide on the Apps downloaded from the App-Store? I get that their source is open and reviewed and trusted but what is this worth when there is no way to tell if users are actually using their version/builds when installed from App-Stores. Same holds true for the necessary servers they maintain. Don't get this wrong please: this is still probably THE best solution right now, which simply as well has its security limitations, right? Is there any work ongoing on a kind of "verification process" for Apps like these? How can an end-user tell if the binaries running on their device are untempered with? /sorry for hijacking ;)

hannob 11y ago
The solution is called reproducible builds. I'm aware f-droid is working on these, but most of the work is currently happening more in the Linux distribution space (Debian is leading that cause). I hope in the future we will be able to say "if it doesn't have a reproducible build process it's not to be considered trustworthy". (Also: I think this question is mostly independent from the disagreements between moxie and f-droid - they were regarding other issues.)
- alkonaut 11y ago
  Aren't builds typically reproducible? What makes builds non-reproducible? I know the Debian folks are very enthusiastic about reproducible builds, and for a huge system I can see that things can vary -- but what tends to be varying in the case of individual components? If I build a library from the same revision of a source tree I expect the exact bits to come out, if the same compiler version was used? When does it not? Is it a problem with C/C++ in particular, where toolchains are complex? Or would non-reproducible also be a problem e.g for a Java library? Googling reproducible builds mainly gets you Debian info, not a general description of the issue
  - sandworm101 11y ago
    A build is not reproducible where it incorporates both open and closed code. A company may "open source" some important stuff (encryption algorithms) but keep enough code closed that the final build cannot be duplicated from the "open" code. It is therefore difficult to judge whether the open code has actually been adopted properly, or whether any closed code hasn't created new bugs.
  - wila 11y ago
    No builds are not easy to reproduce bit by bit as there are much more factors as the actual source. For example: - compiler version used - date / timestamps at the time of compile - build id's A good article on this can be found here: https://blogs.kde.org/2013/06/19/really-source-code-software https://blogs.kde.org/2013/06/19/really-source-code-software
- buu700 11y ago
  Reproducible builds are on our very-near-future roadmap at Cyph, which will be important to mitigate a hypothetical scenario in which we somehow lose our minds and deploy code that differs from the GitHub repo. We control the whole packaging/signing framework (WebSign), so there isn't any need for us to wait on a third party to roll this out.
tomjen3 11y ago
You can always compile the programs yourself - you will have to pay for a dev account for iPhone (I think) but Android is free and you can sideload the new app you trust.
- ikeboy 11y ago
  If you have the source code, Apple now allows you to install it on your own device without paying for an account.

hannob 11y ago

The solution is called reproducible builds. I'm aware f-droid is working on these, but most of the work is currently happening more in the Linux distribution space (Debian is leading that cause). I hope in the future we will be able to say "if it doesn't have a reproducible build process it's not to be considered trustworthy". (Also: I think this question is mostly independent from the disagreements between moxie and f-droid - they were regarding other issues.)

alkonaut 11y ago
Aren't builds typically reproducible? What makes builds non-reproducible? I know the Debian folks are very enthusiastic about reproducible builds, and for a huge system I can see that things can vary -- but what tends to be varying in the case of individual components? If I build a library from the same revision of a source tree I expect the exact bits to come out, if the same compiler version was used? When does it not? Is it a problem with C/C++ in particular, where toolchains are complex? Or would non-reproducible also be a problem e.g for a Java library? Googling reproducible builds mainly gets you Debian info, not a general description of the issue
- sandworm101 11y ago
  A build is not reproducible where it incorporates both open and closed code. A company may "open source" some important stuff (encryption algorithms) but keep enough code closed that the final build cannot be duplicated from the "open" code. It is therefore difficult to judge whether the open code has actually been adopted properly, or whether any closed code hasn't created new bugs.
- wila 11y ago
  No builds are not easy to reproduce bit by bit as there are much more factors as the actual source. For example: - compiler version used - date / timestamps at the time of compile - build id's A good article on this can be found here: https://blogs.kde.org/2013/06/19/really-source-code-software https://blogs.kde.org/2013/06/19/really-source-code-software
buu700 11y ago
Reproducible builds are on our very-near-future roadmap at Cyph, which will be important to mitigate a hypothetical scenario in which we somehow lose our minds and deploy code that differs from the GitHub repo. We control the whole packaging/signing framework (WebSign), so there isn't any need for us to wait on a third party to roll this out.

tomjen3 11y ago

You can always compile the programs yourself - you will have to pay for a dev account for iPhone (I think) but Android is free and you can sideload the new app you trust.

ikeboy 11y ago
If you have the source code, Apple now allows you to install it on your own device without paying for an account.