[jMyles]

> Open source at least provides a facsimile of recourse - just go read the code - but how much of your currently-running open-source code have you actually read?

Wait, what? That is not the recourse that open source provides.

The great thing about open source is that you don't need every person to read the code, just one person who can either catch or verify the absence of user-abusive material.

Moreover, even if zero people read the code today, it is preserved so that state (or corporate) abuse can be revealed later, providing another disincentive to introduce abusive material.

[stavrianos]

Alright, but now you trust that person. Which might be fine, but as an exercise in paranoia is not the greatest answer. As a social proof, somewhat better - create the opportunity for many people to examine, and at least some of them will find things and talk about it. Now the trust is in the shape of the general mass of reviewers - that it contains people who will review the code and reveal their findings.

[Zigurd]

> Alright, but now you trust that person.

In a word: no. With open source code, you could use software authored by the NSA, like SELinux, or you could even hire a manifestly untrustworthy party like Hacking Team to author some code and still be able to trust the code.

In Apple's case, there is a fairly good reason to trust Apple because it would be a hell of a kabuki theatre production to have the FBI and Apple battle in a Supreme Court case while colluding in secret. But would you trust a defense contractor? A telco? Limit or ideally eliminate the need for trust. Fortunately it is possible to reduce the need for trust below having to trust groups or individuals.

[alextgordon]

Isn't that discredited by Apple's "goto fail" bug? A critical function was mistakenly circumvented in an extremely transparent way, and yet the source code sat on their website for a long time without anybody noticing. Nobody even ran coverity on it.

[fleshweasel]

goto fail was in OpenSSL which many organizations use, but your point still stands.

[stouset]

No, this was a bug in SecureTransport, Apple's custom TLS implementation.

[fleshweasel]

Oops. You're right. Sorry.

[awinter-py]

It's not just reading the code -- static analysis tools can provide some guarantees that the software isn't exfiltrating information from your box, making unsolicited connections, or leaving unexpected ports open.

In theory, we can perform the same analysis on the compiled program's bytecode. As the decompilation ecosystem gets better, we may view machine code or bytecode as transparently as source code.

Of course, your apple EULA may bind you against decompiling the machine code -- but it can be argued that you're not 'reverse engineering', you're just doing a virus scan.

[nradov]

Static analysis tools are very useful for identifying accidental security defects, however they really don't guarantee the absence of a deliberate security flaw or back door. You have to assume that the attacker has access to the same static analysis tools, and can thus find tricky ways to cause false negative scan results. Or perhaps the static analysis tool itself has been compromised?

[awinter-py]

All fair points -- nothing is guaranteed, but sooner or later you have to trust your tools. Like, maybe there's a backdoor in your compiler so certain lines of code are compiled so that they notify chairman mao when you shop for red notebooks ... .

The repeatable builds projects go a long way towards preventing this by producing identical bytes from different compilation chains. Ultimately it's good to have a combination of static analysis, multiple toolchains & 'many eyes' providing checks and balances for each other.

[marcosdumay]

How do you know you are running the same software that everybody else is reviewing?

[pdpi]

One solution is reproducible builds and signatures.

The bitcoin community, for example, uses Gitian to reproducibly build bitcoind. Both Bitcoin Core and Bitcoin Classic host repositories with signed hashes for the output of those builds:

https://github.com/bitcoin/gitian.sigs https://github.com/bitcoinclassic/gitian.sigs

(As I understand it, several Altcoins do the same as well)

Anybody can follow the published guides for how to perform such a build, and compare their results with the published ones. Because the published hashes are signed, you have a reasonable degree of certainty that a variety of people are involved in the process, which also gives you a greater degree of confidence in the quality of the binary releases even if you don't want to compile it yourself (and, if you do compile it, you're free to add to the consensus that the binary build is good by PRing your own results)

[dankohn1]

Please see the Reproducible Builds project, a vital contribution to answering this question.

https://reproducible-builds.org/

[marcosdumay]

Reproducible builds do not cut it. If you have a known good binary signature, you'd also have a known good source signature and wouldn't have the problem.

Or, to put it in better words, where do you get the certificate to check your build from? At extreme paranoia levels, you simply can never be sure you have the same software as everybody else, thus the only safe alternative is reviewing your copy yourself.

(How do you know the computer is showing you the correct contents of your files? Didn't think that well enough yet.)

[dankohn1]

Diverse Double Compiling is a proven solution to the On Trusting Trust problem [0]. So, if a package maintainer signs a package and posts that signature on an https page, I can have a high level of confidence that the software I compile and run on my machine is identical.

Here is some advice from Schneier on running secure software against a state-level adversary [1][2]. However, even that is not immune from a black bag job [3].

[0] http://www.dwheeler.com/trusting-trust/ [1] https://www.schneier.com/blog/archives/2013/10/air_gaps.html [2] https://www.schneier.com/blog/archives/2014/04/tails.html [3] https://en.wikipedia.org/wiki/Black_bag_operation

[jMyles]

Surely you aren't suggesting that a reasonable answer is to read the code yourself and compare it to a known version?

Obviously, the mainstream way is a hash-based file verification.

Which again, everybody needn't do - only a small number - in order to catch a bad actor in the act.

But I presume you are trying to make some bigger point. What is that?

[marcosdumay]

It's not reasonable at all. But the only correct answer is reviewing the code yourself.

[crdoconnor]

In Debian, with reproducible builds.