4

When i compile source code to get a working safe Tor package, what i produced have different hash from official Tor binary in download section... is this a compiler problem or that's normal compilers add random data and we can't check Tor official binaries are safe or backdoored? this problem is only for C code compilers or same problem exists for java (orbot) and there is no way to verify compiled binaries by source code?

Why is it common to get a different binary from compiling the same source code? Can somebody please explain how reproducible builds are achieved and why the same isn't possible with Java?

Improve this question

1 Answer 1

Reset to default
3

This is normal for the Tor 0.2.3 series.

If however you are trying to compile 0.2.4 or later, then the desired result is that it would be identical, and thus produce the same hash. As this feature is still under development however it's possible it's a (known or unknown) bug. To attempt this, follow the README in the build scripts. This would handle the case of the official binaries being backdoored.

For the second part of your question, about whether Java implementations have the same unverifiable build problem, the same problem exists. Various Java compilers will compile the source into Java Virtual Machine code differently with different optimisations. As far as I'm aware there is no effort to get Reproducible Builds for Orbot. The situation is (slightly) different however here as then you are also relying on the JVM program that interprets the compiled bytecode into appropriate instructions for your machine, which adds another layer of verification needed, depending on how concerned you are about the backdooring of software.

Improve this answer
5
  • If someone knows which specific version/git-hash reproducible builds became normal, please add that in. I'm almost certain that it wasn't the initial 0.2.4 version.
    – Megan Walker
    Oct 21, 2013 at 19:02
  • 1
    Getting reproducible builds is Hard. Just building Tor in your normal build environment won't do it. The way the TBB 3.x tree does it is to bootstrap a virtual machine, with specific compiler and library versions, fake the date, re-order directory entries to specific orders, etc. It's not for the faint-hearted. See the scripts in gitweb.torproject.org/builders/tor-browser-bundle.git for working examples.
    – weasel - Peter Palfrader
    Oct 21, 2013 at 19:09
  • That's true. I assumed in my answer that they can follow the build instructions stored in the READMEs, although I could make that more explicit. I believe that the instructions (and invoked scripts) handled the actual version dependencies. Further detail on how exactly a reproducible build is achieved, under the hood, would be a separate question I think.
    – Megan Walker
    Oct 21, 2013 at 23:44
  • Yeah, I don't think following any build instructions on how to build Tor will give you reproducible builds, alas.
    – weasel - Peter Palfrader
    Oct 22, 2013 at 5:47
  • what's the problem why we get a different binary from compiling same source code? can somebody explain how reproducible build is achieved? and why Java can't do that?
    – iTor
    Oct 22, 2013 at 6:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.