> You can never 100% know for sure if that code doesn't have a security backdoor
How does compilation methodology help with analyzing millions of lines of code?
> This is why the UNIX philosophy of distributing only source code and building locally for apps is important. You can never 100% know [...], but at least you have the opportunity to self audit.
My comment was a reply to "distributing only source code and building locally for apps is important", and I pointed that reproducible builds enabled an alternative method to achieve the same without requiring everyone to rebuild from scratch (which is arguably worse from the perspective of uncertainty). And that's all. I didn't have anything to say on the audit question.
But if you want to nitpick, yes, this reply is incomplete, and to defend my comment properly, I should've quoted the first (and only the first sentence) from the comment which I was replying to clarify my point. On the other hand, I think it would be painful to do a full-time proofreading of every single comment I'm going to make.
Ken Thompson “Reflections on Trusting Trust”
David A. Wheeler’s Page on Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers
In particular see the new section on that page, "Real-world application of DDC".
As an example, OpenSSL is open source and widely used, yet even they missed heartbleed.
Being open source doesn't magically make software perfect or free of bugs.
Presumably they didn't. The article states "employees in the engineering and research departments repeatedly identified vulnerabilities in the products’ designs that they were mysteriously prevented from fixing", which implies that all it takes is for competent people to view the source code to expose the sort of fraud that was happening here.
As a fairly extreme example, consider what it would take to backdoor GnuPG. It is distributed to multiple platforms/OSes, most of which allow anyone to check both the signatures on the source code and then recreate the binaries.
Also it's not exactly clear how an end user would discover that the Debian package they installed had a different checksum from the version that was reproducibly built, or if sufficiently independent teams are re-creating these checksums and have a way of notifying people of discrepancies.
[0] https://tests.reproducible-builds.org/debian/rb-pkg/unstable...
[1] https://sources.debian.org/src/gnupg2/2.2.20-1/debian/patche...
We need independent crowdfunded external audits for that like the one performed for TrueCrypt.
I still actually wonder what actually happened to TrueCrypt. Did a dev get threatened with a NSA or FBI NSL? Did they get asked to implant a bug so they shut it down instead? So many questions.
> WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues.
The phrase “not secure as” is interesting as the first letter spell out NSA.
Plus, "Using TrueCrypt" -- "UTC". According to Wikipedia, UTC is "a successor to Greenwich Mean Time" -- Greenwich, London, England. GCHQ is in England! So, obviously, it was a partnership between NSA and GCHQ!
Surely we can come up with even more irrefutable evidence^W^Woutrageous theories if we devote a few minutes to it.
Don't forget also that these organizations heavily participate in forum ops to sway opinion on these topics [1] so operating by consensus can be very dangerous imho. I remember one particular example being the allegations about the FBI paying contractors on ipsec to backdoor it [2]. Which was then met with all kinds of "analysis" about how it wasn't true, and that sort of became the consensus response for a while after, except a year or so later I found a post by one of the devs explaing further detail and it became obvious to me that ipsec had been backdoored and they had just engaged in "consensus cracking". Of course only a few years later Snowden leaks confirmed that ipsec was weak by design and had been being intercepted for quite some time. Also worth noting that while Snowdens doc were released in 2013, the actual docs were mostly from ~2007 era. Think about how much tech has changed since then, and then imagine just how much more powerful the systems are today. Not just the technical systems, but the organizational structures designed to prevent any kind of truly secure crypto from emerging.
2. https://bsd.slashdot.org/story/10/12/15/004235/FBI-Alleged-T...
PS. Also worth noting that Eben Moglen talked about how after the gov lost the crypto wars, he heard a chilling comment about how basically they wanted to do away with anonymity also. I think it's worth noting that anonymity and crypto are hand in hand tech, and if you comp one pivoting into the other is much easier. The gov has worked on comping both quite extensively.
The Crypto AG phones were from a different era.
[†] - then, considering stuff like this, even vetted open source code might be at risk (remember that the NSA can afford the best programmers in the world !) :
http://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thom...
In short: You can basically never know for sure if any complex product is completely secure. You can make guesses, and the more research you do, the closer you get to an answer. At some point, you have enough information to deem a solution "secure enough" for a specific use.
For regular users, it's mostly a question of belief.
<< FinFisher malware is installed in various ways, including fake software updates, emails with fake attachments, and security flaws in popular software. Sometimes the surveillance suite is installed after the target accepts installation of a fake update to commonly used software.[2] Code which will install the malware has also been detected in emails.[17] The software, which is designed to evade detection by antivirus software, has versions which work on mobile phones of all major brands .>>
no backdoor is needed when a users behaviour will let you in. it helps greatly when the service provider co-operates
Putting something into the App Store somehow makes the app itself vulnerable?
Or, the App Store tends to attract already vulnerable software?
Presumably the governments who purchased systems from Crypto AG had people educated in security do some due diligence on Crypto AG's products before purchasing them. If they didn't realize that the products were compromised by the US, what chance do I have?