[tahoe-lafs-trac-stream] [tahoe-lafs] #2057: deterministic builds using gitian

[tahoe-lafs]

#2057: deterministic builds using gitian
-----------------------------+-----------------------------------
     Reporter:  leif         |      Owner:  daira
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:  undecided
    Component:  unknown      |    Version:  1.10.0
   Resolution:               |   Keywords:  install security eggs
Launchpad Bug:               |
-----------------------------+-----------------------------------

Comment (by zooko):

 I love the idea of reproducible builds! It allows everyone to help
 everyone else in identifying bugs, backdoors, etc. With reproducible
 builds, the work that individuals, organizations, or companies put into
 verifying the software they use benefits all other users of that software.

 Now, Tahoe-LAFS itself doesn't contain any native (C/C++) code that needs
 to be compiled. Do we even need to do anything to make this "deterministic
 build" idea happen? Or is it somebody else's problem?

 Who downloads and installs Tahoe-LAFS, and how do they do that, and how
 can the make sure that they're getting the same thing that other users of
 Tahoe-LAFS get?

 Well, here's an example, Debian:

 http://packages.debian.org/search?keywords=tahoe+lafs&searchon=names&suite=all&section=all

 How can a Debian user test whether
 http://ftp.us.debian.org/debian/pool/main/t/tahoe-lafs/tahoe-
 lafs_1.9.2-1_all.deb matches the same "tahoe-lafs_1.9.2-1_all.deb" that
 would be built by someone else from the same source?

 Here is Debian's wiki page on reproducible builds:

 https://wiki.debian.org/ReproducibleBuilds

 By the way, Tahoe-LAFS's ''dependencies'' could contain bugs, backdoors,
 surprising enhancements or regressions, etc. To help everyone think
 clearly about this, let's move all discussion of dependencies (including
 [//trac/zfec zfec] and [//trac/pycryptopp pycryptopp], of which we are
 also the maintainers) to separate tickets specific to the dependencies.

 So, what's the next step on this? Maybe we could ask the Debian
 Reproducible Build team to make Tahoe-LAFS be a test case for their new
 process, and we could collaborate with them?

 Are there other packagers who are trying to solve this problem with whom
 we could collaborate?

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2057#comment:4>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage