[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:  daira
         Type:  task           |     Status:  assigned
     Priority:  normal         |  Milestone:  soon
    Component:  documentation  |    Version:  1.10.0
   Resolution:                 |   Keywords:  openitp-packaging build docs
Launchpad Bug:                 |
-------------------------------+------------------------------------------
Description changed by daira:

Old description:

> 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].

New description:

 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:

  * Tahoe-LAFS as built via setup.py (using setuptools and/or pip), and
  * the MAC OS X (#182) and Windows (#195) packages

 but does not include Tahoe-LAFS as packaged by an operating system
 distribution or package management system.

 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#comment:2>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage