3 ms·
You can't validate anything about an open source project either unless you have repeatable builds. Real audits can be source-assisted, but do not rely on anyone
by lvh 8y ago
You can't validate anything about an open source project either unless you have repeatable builds. Real audits can be source-assisted, but do not rely on anyone pinky-swearing that this is actually the checkout that eventually produced the apk.
- lrvick 8y agoI do agree reproducible builds are the only solution to have practical evidence a given binary came from given source code. F-droid does this, which is why I personally don't consider any clients that are not willing to undergo that rigor. "AOSP" support in this context implies f-droid and implies reproducible builds, but maybe I should break that out more clearly.
- lvh 8y agoThis is not responsive to the core of my argument that nobody who actually audits and analyzes this stuff will tell you that source availability is necessary or even useful for figuring out if a particular application does what it says it does, unless you’re building the entire thing yourself off a trusted buildchain. Even if you have repeatable builds you still audit what the thing actually does.
- Leace 8y agoEven with repeatable builds there are some ways to exploit the system, for example sending a targetted binary to audience that does not check the binaries, or sending a malicious update that exports all your history when you won't notice it (at night?) and then sending a good update to cover up. Mozilla has done some research to close these issues [0] but until this is enforced on a system level reproducible builds won't solve the underlying problem. [0]: https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency