In any other context I would dismiss this comment as a troll, but yeah.. Any program that passes itself off as "secure" and is closed source, in this climate, is immediately suspect.
It is possible to analyze the behavior of a program without access to the source code that makes it easy to recompile and distribute modified builds. I routinely open binary files in disassemblers to read through their behavior. Yes, it is possible to obfuscate the hell out of parts of binary code, and that would certainly throw up a red flag for me, but concentrating on the source code seems to miss the point that source code can also be obfuscated, if the source code looks "too weird" we probably aren't going to trust it either, and it is also possible to hide a bunch of behaviors across wide areas of "open" "clear" code (so nothing looks "too weird" at any given place in the code).
To be very explicit about this, as I think this is a very subtle problem that people tend to totally misunderstand: if I wanted to distribute a chat program and have it be "evil" I would not distribute a binary with hidden behavior (if nothing else, when you find this code in my binary I'm pretty damn well screwed ;P): I'd instead distribute an open source program that involved a threaded work queue for handling multiple socket connections to peers and which had a few very subtle use-after-free race conditions that would only come up under nearly impossible timing scenarios that I knew how to trigger and exploit, giving me complete control of your client whenever I wanted.
These are the kinds of bugs people use to attack open source "secure" web browsers like Chrome year after year at Pwn2Own because people are simply bad at concurrency. In this sense, I'd thereby trust a closed source web browser that had no threads or which was implemented in a type-safe garbage collected language (executed on a simply-engineered runtime from someone separate that I trusted, which could also be closed source for all I care) a lot more than I'd trust Chrome. I'd even probably have an easier time understanding what it is doing disassembling it than reading Chrome's code. (To be clear, such a browser doesn't exist: probably you should use Chrome.)
Actually, there has been some recent research [0] in cryptography that shows it is possible to produce binaries that are obfuscated in such a way such that they are computationally infeasible to deobfuscate (see the linked reference for a formal definition of indistinguishability obfuscation).
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.
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?
Your argument is a bit disingenuous. You say you'd trust simple closed-source software more than complicated open-source counterparts. That's a false dichotomy. Open source X is always more easily auditable than closed source X.
I don't think many people are worried that BT will be evil. I think many more people are worried that they'll be incompetent, and it's very hard to be competent at cryptography. That's why we want the source.
From a "non US person" perspective, I go to BitTorrent's website and read:
Company Overview
BitTorrent Inc. is an Internet technology company based in San Francisco.
And immediately I've got _two_ things to worry about - 1) "will BT be evil/incompetent?", and 2) "will BT be leaned on by the NSA and be coerced into being evil?"
If you're a US company (or individual, or a company with US based management, developers, investors, or infrastructure) who are promoting security-related products in the post-Snowden era – many of us outside the US now have very good reasons to apply extra scrutiny to those products. Opening your source will make a _big_ difference in how readily suspicions of evilness can be allayed. As saurik points out upthread, having the source available doesn't guarantee the rest of the open source community will find and fix any carefully-enough-crafted backdoors, but keeping the source closed sends a strong message…
From a US perspective: The NSA doesn't lean on non-US companies because it is fully authorized to just hack them directly. Your data kept in foreign countries don't even have the nominal legal protection that US data does.
Unless you've got unbreakable security the NSA is well funded enough that it's irrelevant where you do business.
Except that in the case of non-US companies NSA has to do the actual hacking. In case of US ones they simply need to "ask" a company to, say, handle them their master keys - much easier.
Ok, then I will say your argument is a bit disingenuous, as I did not compare "open source X" to "closed source X": I am trying to show that "is it open source" is just one of many variables that you might consider while evaluating the security of a program, and I am further attempting to claim that it is not even the most important of these variables. In the real world, we are choosing between software that differ in many ways, not just one: all individual dichotomies are "false".
I mean, I could also say the argument "you can't trust closed source software for this stuff" is also "a bit disingenuous" via the analogous argument that that open vs. closed is a "false dichotomy": a single-threaded/type-safe/un-obfuscated X-source program "is always more easily auditable" than a multi-threaded/type-unsafe/obfuscated X-source program. Now, the question becomes "what variables are more important to you, and will your reactions be 'knee jerk' or rational"?
Sure, it's only one variable. I disagree that it's not the most important one.
You can audit a multithreaded open source program much more easily than you can audit a single-threaded closed source program. Merely compiling it adds more obfuscation than making it needlessly, complicated will, and making it needlessly complicated will immediately raise red flags.
You don't need to analyze an open-source program to see that it's been obfuscated, and, if it claims to do anything that requires security, that would probably be enough to make you suspicious.
My ultimate point is that compiling is a form of obfuscation that has extreme plausible deniability. There's no form of obfuscation that will complicate the code of an open source program as much as compiling it will, while still looking as innocuous as compiling does.
> You can audit a multithreaded open source program much more easily than you can audit a single-threaded closed source program.
I think this is our core disagreement, as I've been pretty clear about how I don't just accept this statement at face value given the large class of subtle bugs that can and do occur constantly in multi-threaded systems. I find reading through and finding bugs in complex binary-only buffer-management or even cryptographic systems "easy" (time consuming, but not requiring much brain function; even obfuscation just adds time and effort, it doesn't require greater intelligence); yet, I have never managed to remove every single concurrency bug from an open-source project I maintain that only actually uses threads to separate tasks like "searching" from "downloading update" (of course, I likely didn't put as much effort into it, so this doesn't prove anything of course: but I hope it makes you think), and I've seen people "much smarter than me" (working at Google and Apple) fail at doing so in systems that are "much more important" (working on Chromium and WebKit).
You might then just say that I'm probably just stupid and that a more reasonable programmer wouldn't have the same kinds of issues, but "concurrency is hard" I had assumed was a well-known issue. (And again, I think that this all becomes more more interesting to think about once you realize that a "backdoor" left by an intelligent opponent is going to be nearly indistinguishable from a "bug". At least once a year there is some obscure privilege escalation bug found in the Linux kernel: I think it is interesting to at least consider momentarily that any of those might have been a backdoor, and not a bug; the concept of what constitutes purposely malicious code updates tends to be way too narrow in my view, and leads people to only consider back doors that are easy to see when you print out the source code.)
> There's no form of obfuscation that will complicate the code of an open source program as much as compiling it will, while still looking as innocuous as compiling does.
Yeah, no: I seriously read through compiled code every day. I was doing a lot of reading through compiled code yesterday while working on figuring out why Substrate isn't working on iOS 7 for example. I am much much much more afraid of the bugs that are latent in a large multi-threaded project that has "lots of hands in the cookie jar" so-to-speak than of a simpler implementation distributed as a closed-source binary. I'm likewise more afraid of open-source projects that accept patches from large numbers of people (which means more people who might be actively /trying/ to add difficult-to-see exploitable bugs), or of projects that are implemented to run as native code versus ones that run inside of type-safe virtual machines (especially if the virtual machine is coded to a spec and I get to select the one it runs on).
I think that's missing a major point (I'm kind of agreeing with you/considering that required for 'secure', I'm not on Saurik's side of the debate):
Open source means it's not going away. I won't, ever again, buy into a network that I cannot keep alive. Which is one of the reasons I don't use Whatsapp and actively prevent my family from using it. No G+. Leaving GTalk (Sorry, 'Hangout').
BTSync? Nope, unusable. BTChat? Same. Even if some highly trusted party would explain to me that BTChat is the most secure network, period: As long as I don't see the means to keep that thing alive it is just another potential trap.
To be fair: charging for peer-to-peer software that is freely redistributable doesn't work as a business model. You make money in open source by selling related services (e.g. github, Android) or support (Red Hat). You can't do it by licensing the product.
That doesn't invalidate the point above though that in the modern world a tool like this can only be considered "secure" if the implementation(s) are completely open. It's just a poor product decision on the part of BitTorrent.
If the UI module does encryption and decryption, and if the said encryption is good enough, why would you care if the transport layer steals your encrypted data?
Interestingly, you can. Limewire was open source, but charged for a "pro" version. (which was also open source, with the exception of some build files)
The biggest problem with all of it was that there were a bunch of scam sites that added malware, built binaries, and bought "lime wire" keywords on google.
On the other hand, I don't think OSS is to blame for that--the scam sites could have just as easily distributed any binary.
> You make money in open source by selling related services (e.g. github, Android) or support (Red Hat). You can't do it by licensing the product.
This is where the distinction between "free" (as in freedom) and "open source" is helpful.
You can, hypothetically, release the source code of a project under a license that prohibits compilation of that source code (or, prohibits running anything other than the paid binary of the source code). This would allow people to view and theoretically vet the code; they just can run it (legally) without paying for it.
Not that I would like to encourage such behavior, or think that it's valuable. But it's an important distinction to remember.
> release the source code of a project under a license that prohibits compilation of that source code
Such a license would qualify for neither "open source" nor "free software" under the relevant official definitions though.
Yes, it would be reviewable for bugs and probably preferrable to a blob. But without the ability to verify the complication you'd have no assurance that the proprietary code was actually built with the reviewed source. Basically this would just be a stunt.
If the license said that you were in violation if you executed the built code but there was instructions to build the exact version that is distributed it would still allow people to verify that the binary was built from the provided source.
I recall Transgaming Wine had a model that was effectively this, it was difficult for a laymen to build the source and binaries couldn't be distributed freely but the source was still available.
Only enterprise companies can survive on the support business model; it doesn't work for consumer or SMB because they just won't buy support contracts (I'm not counting scams).