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.