reproducible builds

[leif]

It would be good to have the official packages of Tahoe and all of its dependencies built using Gitian.

From ​http://gitian.org/:

Gitian uses a deterministic build process to allow multiple builders to create identical binaries. This allows multiple parties to sign the resulting binaries, guaranteeing that the binaries and tool chain were not tampered with and that the same source was used. It remove the build and distribution process as a single point of failure.

XXX This description may be obsolete as this ticket evolves -- please read the comments and maybe we'll update this description if we converge on an idea of what the issue is.

[daira]

Sounds good to me!

[leif]

​This LWN article contains some worthwhile links on the subject.

[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 zfec and 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?

[zooko]

P.S. The original description and title said it would be good to have the official packages of Tahoe-LAFS and all of its dependencies built using gitian, but I have a few problems with that. First, there aren't official packages of Tahoe-LAFS. Second, I don't understand why gitian is either necessary or sufficient for the goal of reproducible build, and I don't like what little I understand of its approach, which is virtual-machine-based.

[daira]

Replying to zooko:

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?

+1