Yes. Even more simply, it is an impossible problem in the general case to even determine in a given x86 binary what parts are code and what parts are data (there was someone at RV '04 that published a paper on that result while working on his CodeSurfer binary analysis tool).

This does not, however, contradict my argument: as we can take a binary and generate really horrible C code from it (by just emulating via C, unrolling the instructions) the same result is true of source code; however, we would find that block of code highly suspicious ;P.

Again: if I wanted to give myself a backdoor into a chat program, I wouldn't distribute a backdoor into a binary, I'd provide open source code with subtle bugs that would take people years to find and that when found would look like honest "concurrency is hard" mistakes.

I am not saying that whether something is open source or not is totally irrelevant, but the people I'm responding to seem to be having this gut reaction "if it isn't open source it can't be trusted", so I'm attempting to provide enough context to show that it isn't that simple.

I think there's also a bit of "if the crypto can be trusted, opening the source code doesn't weaken it and helps build trust".

Personally, I'm running BTSync - and even though I've got it syncing EncFS encrypted data, the app has enough privileges to read the unencrypted versions of those EncFS filesystems if it were instructed to.

I'd feel happier if a few trusted security experts from a few different countries/jurisdictions had blogged about their analysis of the source code and the likelyhood of the binary produced from the source being either intentionally or unintentionally compromised.

Having said that, as you point out, we've got the Chrome source, lots of people look very hard at it, and it _still_ fails year after year… Hopefully, BTSync and BTChat (or my hypothetical Open Source reimplemetations) are significantly less complex than a full featured browser, and not would not require nearly so much focus on performance that "provably secure" or perhaps just "significantly less likely to have obscure bugs" coding techniques could be used in spite of speed penalties - browser vendors have significant motivation to optimise for speed above all else, hopefully the much smaller subject domains of sync or chat clients would allow security to sensibly be prioritised instead.

Even more than that, if one wants to insert backdoors in OOS, one could easily do that getting barely noticed.

A program might be open source, still the binaries offered for download might be compromised. Who is able to notice that now?

You might compile the software yourself, but the majority of users wont.

You might have reverse engineered a closed source software, but I guess you won't do that for the OSS binaries.

Honest question: if the source code is compiled with the same compiler (although different computer), will it give a different binary with a different hash?

Even compiling the source code with the same compiler, same build options, and same computer will generally generate a different binary with a different hash! Special effort is required to generate "deterministic builds", sometimes seen for e.g. verifying the integrity of gambling software. Here's what one fellow has been going through in an effort to accomplish that:

http://stackoverflow.com/questions/1180852/deterministic-bui...

Potentially yes if the compiler is not configured (at build time) with the same options and the same optimization levels are not used when building the source.