But how often is that really done? And to be honest, it can be quite hard to spot critical bugs or backdoors, just look at http://www.underhanded-c.org/
The bitcoin development community solved the problem of mapping source code to a binary build. Check sums or signatures of binaries is not sufficient. Open source is meaningless if you cannot verify the source maps to the build and you're running critical software with irreversible consequences. E.g. a bitcoin transaction or a dissident being imprisoned from state surveillance eaves dropping on communications.
App stores seem to be getting progressively more hostile to this kind of thing though - you can't just download an APK / iOS app, you have to do it through a device. This lets the stores do "app slimming" (and per-country / per-carrier customized apks) to remove resources you don't need (like binaries that don't match your architecture), which would change the checksum. Which is useful, but inconvenient for this goal.
Something like fdroid may be supportive of this, which would be cool. But I wouldn't expect the mainstream ones (or Apple) to ever embrace it - it'd be a bad user experience / wasted UI space in the vast majority of cases.
Not a particularly useful comment sorry, just "it was possible two years ago if you jumped through some hoops."
And the last time I looked, all the apk-downloaders required your device ID, because Google's API does (for customization reasons) - it's much more of a "you can do this if you emulate a device" than "you can download it". I'm also not sure if the ID works unless you have gplay installed, which you may not have if you're being careful/paranoid enough about security to manually validate apps.
I mean, at the end of the day, it's very easy to verify - if the binary doesn't match what whomever gets when they compile, there better be a reason for it.
Regardless, I don't think this is the biggest problem facing open source.
True, but deterministic compiles are stupendously difficult in most cases. Which is improving slowly, but still isn't usually an option.
https://tests.reproducible-builds.org/debian/reproducible.ht...
I stand by my claim that using software written by a malicious developer is game over in the vast majority of contexts.
The argument here is that open source code can be verified where closed source is explicitly non-verifiable by nature.
> but that the binary was built from this code
Doesn't code signing address this? If not could you explain (for my own learning)?
https://en.wikipedia.org/wiki/Code_signing
> that your operating system and every layer below it is also trustworthy.
Yep, this is the last major piece for true security in my mind. Although there is some movement in the open hardware space as well as USB mounted OSs (http://gizmodo.com/try-the-super-secure-usb-drive-os-that-ed...).
> I stand by my claim that using software written by a malicious developer is game over in the vast majority of contexts.
Sure...perfectly accurate...but in the context you are implying that WhatsApp is malicious. To which I think "hackuser" was interpreting as "closed source is malicious" and therefore offering open source (and by implication Signal) as an alternative.
Might just be a miscommunication moment :-)
This is not a belief that people who actually do software security audits hold. Verifying binary only software is table stakes to a security audit of a third party application as you cannot trust the source provided.
Having source is a bonus for security audits not a requirement.