Bring back reproducible builds #401

New issue

Open

opened 2021-04-05 16:18:31 +02:00 by lyoshenka · 2 comments

lyoshenka commented

2021-04-05 16:18:31 +02:00

(Migrated from github.com)

As a security-conscious user, I need to be able to build lbrycrd from source and be confident that it matches the official release. This is critical to ensure that all nodes remain in consensus.

Requirements:

must be able to create a byte-for-byte reproducible build of the lbrycrd binaries by running a single script
instructions for this script must be in readme.md. it must be clear that this is the official way to build lbrycrd. other ways to build can be listed, but it must be clear that they are not for production use and cannot be guaranteed to remain in consensus.
our CI must use this script to build our releases. it must do basically nothing else but run that script.
the script should take care of dependency checking and installation, erroring if dependencies are not met, etc.
its acceptable to use Docker, but not any pre-existing images. if an image is being used, creating that image should be part of the reproducible build script.
for v1, must work on linux at least. for v2, must work on windows and mac as well.

As a security-conscious user, I need to be able to build lbrycrd from source and be confident that it matches the official release. This is critical to ensure that all nodes remain in consensus. Requirements: - must be able to create a byte-for-byte reproducible build of the lbrycrd binaries by running a single script - instructions for this script must be in readme.md. it must be clear that this is the official way to build lbrycrd. other ways to build can be listed, but it must be clear that they are not for production use and cannot be guaranteed to remain in consensus. - our CI must use this script to build our releases. it must do basically nothing else but run that script. - the script should take care of dependency checking and installation, erroring if dependencies are not met, etc. - its acceptable to use Docker, but not any pre-existing images. if an image is being used, creating that image should be part of the reproducible build script. - for v1, must work on linux at least. for v2, must work on windows and mac as well.

BrannonKing commented

2021-04-05 16:51:28 +02:00

(Migrated from github.com)

We'll have to set the SOURCE_DATE_EPOCH and whatever the equivalent is for CLANG and the cross compiler. We also need to modify the code to ensure that we aren't running with an incompatible version of ICU and that Boost was built with the ICU backend.

juanpc2018 commented

2022-08-22 02:15:35 +02:00

(Migrated from github.com)

byte-for-byte reproducible build

is Near impossible,
unless you have exactly the same version of everything the developer used to make the build.
all libraries, OS, dependencies, etc...

also read:
Reflections on Trusting Trust, by Ken Thompson:
https://www.youtube.com/results?search_query=Reflections+on+Trusting+Trust%2C+by+Ken+Thompson

thats why people with that level of paranoia buy these:
https://www.youtube.com/results?search_query=talos+ii+raptor

The docker image is the "same"...
personally i dont like docker,
i think is much better a real image .vhd / .vhdx
VirtualBox, qemu, kvm, vmware, proxmox, parallels, etc...

> byte-for-byte reproducible build is Near impossible, unless you have exactly the same version of everything the developer used to make the build. all libraries, OS, dependencies, etc... also read: Reflections on Trusting Trust, by Ken Thompson: https://www.youtube.com/results?search_query=Reflections+on+Trusting+Trust%2C+by+Ken+Thompson thats why people with that level of paranoia buy these: https://www.youtube.com/results?search_query=talos+ii+raptor The docker image is the "same"... personally i dont like docker, i think is much better a real image .vhd / .vhdx VirtualBox, qemu, kvm, vmware, proxmox, parallels, etc...

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: LBRYCommunity/lbrycrd#401

No description provided.