Tor at the Reproducible Builds Workshop in Athens 2015
Being able to build Tor Browser several times in a row and getting exactly the same result each time has been an important feature for a while now. It provides a direct link between the source code we provide and the binary that Tor users are downloading and using to surf the web. This offers a number of benefits to all parties involved:
- Users can verify that they really got the binary they were supposed to get
- Pressure on developers to provide a bullet-proof build and signing setup is reduced
- Incentives to pressure release engineers into inserting backdoors into the code are reduced
From December 1-3, 2015 we had the opportunity to discuss these and other topics around reproducible builds with members of different projects. Thanks to the Linux Foundation, the Open Technology Fund and Google, developers from Debian, FreeBSD, NetBSD, Google, the Guardian Project, Coreboot and Tor (to name just a few) were able to attend. The workshop started with exchanging experiences with already existing systems (like Gitian, which we use for Tor Browser). During the three days of the meeting, work went on to explore together future directions for advocacy, commonly used tools, infrastructure and documentation.
We were especially pleased to see the fruitful collaboration on the operating systems level. While it is good to have a reproducible Tor Browser, the security guarantees that it provides are even stronger if the operating systems and the toolchains used to build it can be created reproducibly as well. Moreover, all participants agreed that non-reproducibility is essentially a defect that needs to be fixed. This allows us to treat workarounds (like using libfaketime to avoid timestamp differences in binaries) as mere band-aids and instead focus on addressing the root causes of non-determinism directly upstream.
Thanks to Allen Gunn and the Aspiration team for the excellent facilitation and all participants for the productive and exciting time. See all of you at the next workshop!
Users can verify that they really got the binary they were supposed to get
Pressure on developers to provide a bullet-proof build and signing setup is reduced
Incentives to pressure release engineers into inserting backdoors into the code are reduced
i do not understand how a rogue certificate could be 'inserted' implemented.
do you mean that someone is corrupted in the team (s) ?
are you speaking about compromised laptop/tablet/computer like lenovo in the past ?
are you asking to the tor team (reproducible builds workshop) if a special feature in the tb should prohibit the usage of a rogue certificate ?
> are you speaking about compromised laptop/tablet/computer like lenovo in the past?
Yes, "superfish" style rogue cert. See also Kazakhstan.
> Pressure on developers to provide a bullet-proof build and signing setup is reduced
Please don't reduce that pressure just yet, since few Tor users have the ability to do a build! For example, I don't. Hard enough getting ordinary users to verify the signature of the iso image (Tails) or tarball (TBB).
it is up to you !
You must learn :
how to verify&install properly the operating system-software (easy)
how to choose the right computer-hardware for you (easy)
a patch, a removal tool, some instructions were added after the "superfish" style rogue cert problem.
i read that linus torwald is working about an universal operating system ; maybe this one will contain a special feature protecting against these false or hidden certs.
you could make a request to him !
(unfortunately; i am not informed about 'See also Kazakhstan' and you have not let a https link.)
The reproducible build workshop is a success.
Thanks, but I don't think any of that addresses the question I tried to ask. Which I now see was not sufficiently clear.
> The reproducible build workshop is a success.
"Please don't reduce that pressure just yet, since few Tor users have the ability to do a build! For example, I don't. Hard enough getting ordinary users to verify the signature of the iso image (Tails) or tarball (TBB)."
I don't think the post is talking about end-users so much as users like:
- Linux distro package maintainers, who build a binary package from source and distribute it to the distribution's (e.g. Debain) users. They can verify that the binary matches the one that Tor Project says it should before signing and shipping their package.
- Deployment operations people, who do basically the same thing but within a specific company or organization. This would mean something like doing a reproducible build and verifying it before putting it on a shared NFS /usr filesystem, or the Windows-equivalent way of sharing preinstalled software within a network.
- IT security people, who are responsible for whitelisting specific binaries for execution on computers within the organization. If the binary doesn't match Tor Project's, the OS will refuse to execute it.
- Users of source-based distributions like Gentoo, where the reproducible build and binary comparisons can happen automatically behind the scenes.
- Users of package managers like apt-get, yum, pacman and many more. The package manager can extract the binary from the package and verify it against the Tor Project's hash before installing the package. This won't tell the end-user that the binary is really based on the source they think it is, but it will tell them that the source (and resulting binary) was not modified by the package maintainer or package build server, or in transit. Windows users could do the same thing manually, but it is less useful because Windows binaries are distributed directly from Tor Project while Unix packages are distributed from the distribution's developers.
- End users of any OS would be able to verify their downloaded binary's hash against hashes from other users of the same OS who have actually done the reproducible build. All of those users would have to have been compromised, as opposed to (currently) just the Tor Project developer who PGP signs the binaries.
Some more than others, but any of these methods could be helpful in detecting a compromised build system or machine-code-level backdoors somewhere along the path.