3 ms·

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 sp

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

by hannob 11y ago

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.