zlacker

How do you know that the binary you run actually corresponds to the source code you read?

EDIT: and would you then also review every commit to make sure nothing bad gets introduced? No, at some point you have to place trust in the vendor, the developers, independent audits, etc.

>>drdrey+(OP)
Determinism.

https://tests.reproducible-builds.org/debian/reproducible.ht...

We're making great strides into software being completely deterministic. The Bitcoin project for many years has had completely deterministic binaries and a ceremony process for GPG signing the output with many individual parties.

>>drdrey+(OP)
You can build the source locally, then compare the MD5 hash value of your build to (1) the hash value they post publicly for their build and (2) the actual hash value of their build once you download it.

Assuming all three match, you know that the binary matches the source.

Someone who is more technically inclined can probably go into more detail on this.

>>drdrey+(OP)
How do you know the compiler actually compiles the source code to the binary you expect without injecting backdoors? How do you know that the hardware actually follows the instructions in the binary as they are specified?

How do you know you're not living in a computer simulation in which the operators can access your data without any backdoors whatsoever?

>>drdrey+(OP)
Just to be clear software assessment doesn’t only happen at the source level. It happens at the binary downloaded at the device.

>>shawnz+T
See Reflections on Trusting Trust [1]

[1]: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

>>shawnz+T
Build it yourself.

>>shawnz+T
To make an apple pie from scratch, first you must create the universe. :)

>>ciaran+w
we are talking about security, and you brought up... MD5?

>>ciaran+w
This is actually more involved than it sounds. It is pretty easy for the compiler to introduce nondeterminism and result in slightly different binaries. I know this for a fact because I fixed a couple bugs like this in LLVM.

For the curious: we actually were intentional about finding these, by compiling many programs with the same parameters on different machines. One with a 32 bit OS and toolchain, the other one on a 64 bit machine, and we would get alerted when we produced binaries with a different checksum.

>>RL_Qui+e
See my other comment about determinism: https://news.ycombinator.com/item?id=23424925

Trying to get a bit-to-bit equivalent of a binary lifted from the app store sounds challenging to say the least.

>>shawnz+T
That's my point, you can't establish trust by checking everything yourself. So you delegate to other things as an approximation. In this case, Signal seems to be reputable, have competent developers and afaik no history of leaks or malevolence so I would rely on that rather than a half-assed source code review.

>>khc+95
We’re talking about the forest, and you mention... one of the trees?

>>shawnz+T
For countering subverted compilers you can use diverse double-compiling (DDC), see https://dwheeler.com/trusting-trust/

>>shawnz+T
With electron microscopes of course!

Cartesian doubt becomes pointless at some point. If you're worried that the deep state has implanted microchips in your brain to prevent you from analyzing signal, it probably doesn't matter because at that point they wouldn't need to hack signal to get to you.

A less snarky and more realistic answer is: threat models and risk assesment. (Non-divine) adversaries generally have limited resources. The limit may be high, but its still there. You can realistically worry about a government coercing a service to hand over keys, because that's easily within their power. On the other hand, having a giant conspiracy-trusting trust style-where every compiler & microchip has a backdoor that is inserted into every tool ever compiled, is a bit unrealistic. It would take thousands of people to be in on it to pull it off, spread across many countries (who hate each other) over at least 50 years. Having that many people, especially academics, keep that type of secret for that long is basically impossible. If they could do that, it would be child's play to have most of the protestors be gov agents, so if you think this is realistic, worry about that first. Anyways, in my judgement governments don't have that kind of power, so its probably not something to worry about.

So, to conclude, estimate the level of power and influence you think your enemies have, and then take steps to rule out the possibilities that your enemies have done the things that are theoretically in their power to do. Start with the possibilities that are most likely multiplied by how bad it would be for you (liklihood*severity = risk)

>>drdrey+g6
Yes, this is more difficult than it sounds - but GP linked to the reproducible builds project which has gotten there already for a lot of software.

See also Guix, which provides tools to challenge servers providing binary packages to see if they match a locally-built version: https://guix.gnu.org/manual/en/html_node/Invoking-guix-chall...

>>ciaran+w
MD5 is not safe for this use case. Assuming the provider is malicious, this is exactly the scenario where MD5 is broken (i.e. it is possible to make source code that compiles a certain way so that you can make another binary that has the same hash but is different. The bright side is the attack would have evidence as there would be certain patterns in the binary that could be detected if you knew how/where to look. That said, just use sha256)

>>RL_Qui+e
There is https://signal.org/blog/reproducible-android/ but it is not complete.