[tbb-dev] Reproducible Builds Summit

Nicolas Vigier boklm at mars-attacks.org
Tue Dec 18 21:55:26 UTC 2018

On Tue, 18 Dec 2018, Georg Koppen wrote:

> 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.
> How does that deal with content signing? Because if you look e.g. at the
> .dmg files we produce there is currently no direct link between the
> build X rebuilders reproduced and the bundle that is getting finally
> shipped. The same holds for Windows although dealing with the
> Authenticode signature is easier here.

I think that in-toto has support for multiple steps between source and
final package. So the main step would be the build, and I think we could
add an other step to make the link between the signed and unsigned package.
This will require having a tool that can deterministically remove a
signature from a signed .dmg file, or add one to an unsigned .dmg file.

So the rebuilders would run both the [sources <===> unsigned package]
and [unsigned package <===> signed package] steps, and clients would
require both steps to be signed by enough rebuilders.

> I had the same doubts when reading, e.g. the CHAINIAC paper about
> proactive software-update transparency (with verified builds)[1], but
> did not have time to follow-up with its authors to check whether they
> got that part actually solved.
> > 
> > = 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.
> Well, the risk here is that this adds another necessary part for getting
> updates to users to the whole scheme, which in turn could get e.g.
> DDoSed during critical update times.

I think the log can be provided as static files. So maybe that could
be hosted on cdn.tpo with the .mar files.

> > - 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.
> What do you mean by the latter? The .mar file you personally downloaded
> during an update?

Yes, currently you can verify the .mar file that the update server
provides you, but you cannot know if it provides the same .mar file
to everybody at all times.

> It might be worth looking closer at those two ideas and compare them to
> proposals like CHAINIAC to get a better sense of where we should head to
> (I skimmed Benjamin's paper a bit and see they have a detailed
> comparison to CHAINIAC which could be a good starting point).



-------------- 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/20181218/596521bb/attachment.sig>

More information about the tbb-dev mailing list