document in what ways Tahoe-LAFS builds are not currently verifiable

[daira]

A long-term goal, ticketed as #2057, is to enable end-users to *verify* that the package of Tahoe-LAFS that they are using was generated from the exact same source code that a security auditor examined.

In order to explain the verifiable build concept, consider this simple diagram:

    distributor: source code ➾ binary package → user

Here we use “➾” to mean “build” — the process that produces usable packages out of source code.

Now consider a security auditor who does a source-code-based examination (as opposed to binary-based, which is called “reverse engineering”). This security auditor will start with the source code, and examine it for vulnerabilities or backdoors.

    auditor: source code → security audit

How can the user who receives a binary package know whether that package was built from the source that the auditor examined?

The “verifiable build” approach attempts to answer that question by having the security auditor perform the “source code ➾ binary package” on their own trusted system, and then taking a fingerprint (secure hash) of the resulting binary package:

   auditor: source code ➾ binary package
   auditor: binary package → generate fingerprint

The auditor then publishes that fingerprint along with their report about their security audit. Users who receive the binary package can take a fingerprint of that package and compare it to the fingerprint in the published report.

   distributor: source code ➾ binary package → user
   user: binary package → check fingerprint

This approach can work only if the ➾ operation performed by the distributor results in a bytewise-identical binary as the ➾ operation performed by the security auditor.

Here is a news article from LWN.net about the concept of verifiable builds (prompted in part by an open letter that we wrote): ​“Security software verifiability”. Here is a post on the tahoe-dev mailing list about our desire to have verifiable builds for Tahoe-LAFS.

The goal of this ticket is to have documentation of the ways in which Tahoe-LAFS builds are not currently verifiable. Its scope includes only Tahoe-LAFS as built via setup.py (using setuptools and/or pip), not as packaged by an operating system distribution or package management system. However, it may be useful to consider how existing projects have approached this problem: ​Debian, ​Tor, ​Bitcoin, and the recent ad-hoc ​reproduction of the TrueCrypt Windows binaries.