reproducible builds #2057

Open
opened 2013-08-08 21:34:04 +00:00 by leif · 5 comments
Owner

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.

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.
tahoe-lafs added the
unknown
normal
defect
1.10.0
labels 2013-08-08 21:34:04 +00:00
tahoe-lafs added this to the undecided milestone 2013-08-08 21:34:04 +00:00
tahoe-lafs added
enhancement
and removed
defect
labels 2013-08-08 21:34:50 +00:00
daira commented 2013-08-08 23:34:42 +00:00
Author
Owner

Sounds good to me!

Sounds good to me!
Author
Owner

This LWN article contains some worthwhile links on the subject.

[This LWN article](https://lwn.net/SubscriberLink/564263/d554156d882bfe0e/) contains some worthwhile links on the subject.
zooko commented 2013-08-31 13:41:39 +00:00
Author
Owner

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?

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?
zooko commented 2013-08-31 13:44:16 +00:00
Author
Owner

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.

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.
tahoe-lafs changed title from deterministic builds using gitian to reproducible builds 2013-08-31 13:44:16 +00:00
daira commented 2013-09-01 05:34:20 +00:00
Author
Owner

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

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/2057#issuecomment-134595): > 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
tahoe-lafs added
packaging
and removed
unknown
labels 2014-09-11 22:24:02 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#2057
No description provided.