[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2357: document in what ways Tahoe-LAFS builds are not currently verifiable

[Tahoe-LAFS]

#2357: document in what ways Tahoe-LAFS builds are not currently verifiable
------------------------------------------+---------------------------
 Reporter:  daira                         |          Owner:  marlowe
     Type:  task                          |         Status:  new
 Priority:  normal                        |      Milestone:  undecided
Component:  documentation                 |        Version:  1.10.0
 Keywords:  openitp-packaging build docs  |  Launchpad Bug:
------------------------------------------+---------------------------
 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):
 [https://lwn.net/Articles/564263/ “Security software verifiability”]. Here
 is a [//pipermail/tahoe-dev/2013-August/008684.html 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: [https://wiki.debian.org/ReproducibleBuilds
 Debian], [https://blog.torproject.org/category/tags/deterministic-builds
 Tor], [https://en.bitcoin.it/wiki/Release_process Bitcoin], and the recent
 ad-hoc [https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binaries-
 analysis/ reproduction of the TrueCrypt Windows binaries].

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2357>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage