[tbb-dev] Reproducible Builds Summit

[Nicolas Vigier]

Hello,

I was at the reproducible builds summit last week. During the meeting
there were discussions about various topics related to reproducible
builds:
 - reproducible builds for various languages, filesystems and distributions
 - bootstrapping
 - rebuilders and user verification
 - software transparency

I think the two most interesting discussions for me were about rebuilders
and user verification, and software transparency.


= Rebuilders and user verification =

Some people from New York University have been working on a framework
called in-toto which can be used to verify before installing a build
that it has been reproduced by a number of trusted builders:
https://in-toto.io/

They have implemented some prototype for Debian.

Here is how it works:
 - some independent organisations are running "rebuilders". Those
   rebuilders fetch new Debian source packages and rebuild them.
   When the build is finished they publish some json files containing
   informations about the source package, and the result of their build,
   and their signature.
 - apt is modified (using an apt-transport) so that before installing a new
   package, it connects to known rebuilders and fetch their build
   informations. If the build has been reproduced by enough rebuilders,
   then the package is installed.

I think it might be possible to implement something similar in Tor Browser,
maybe reusing some parts of their framework.


= Software Distribution Transparency and Auditability =

Benjamin Hof is working on tools for Software Distribution Transparency
and Auditability:
https://arxiv.org/abs/1711.07278
https://debconf18.debconf.org/talks/104-software-transparency-package-security-beyond-signatures-and-reproducible-builds/

He has implemented some prototypes to improve software distribution
transparency in Debian, using a public log server which can be used to
monitor the packages which have been distributed to users. I discussed
with him how something similar could be done in Tor Browser.

Here is how it could work:
- we add a log server which can be used to cryptographically prove:
   * inclusion of an update in the log
   * append-only operation of the log
- when we release a new Tor Browser version, we add checksums of the
  new mar files to the log.
- when the Tor Browser updater receives a new update, it checks if the
  update is in the log, before applying it. If the update is not in the
  log, then the update is not applied.
- independant monitors analyse the logs. They check that all checksums
  published in the log correspond to a known release. They can also check
  that the build corresponding to those checksums is reproducible. The
  log is public, so anybody can monitor it.

The main improvement from this system is that it allows anyone to check
that all the updates used by all users are reproductible builds, while
today you can only verify that for one downloaded copy of the software.

Nicolas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20181217/baa8da57/attachment.sig>