Builds are not reproducible

[sbp]

Using reproducible builds would ensure that users have confidence that the binaries for their architecture and platform were created from the (hopefully) audited and secure sources:

Most aspects of software verification are done on source code, as that is what humans can reasonably understand. But most of the time, computers require software to be first built into a long string of numbers to be used. With reproducible builds, multiple parties can redo this process independently and ensure they all get exactly the same result. We can thus gain confidence that a distributed binary code is indeed coming from a given source code.

There is information on how to do this. Once done, please document this fact for your users so that they can understand the security procedures used in the creation of this app, including the auditing process.

[Roasbeef]

We have a set plan (not yet implemented) to ensure the post-alpha release of lnd are fully reproducible. To my knowledge, there's no known way to ensure that builds of Electron-based applications are fully reproducible.

As a stop gap, once the release of lnd are fully reproducible, as the binary if packaged with the application, users will be able to verify that the bundled binary is indeed identical (and the result of the same build procedure) to the official lnd release. At that point, that just leaves the integrity of the Electron application itself. The entire source code of the application (un minified) is actually packaged as part of Electron applications, as a result the codebase can be fully audited (at least our application, Electron itself is another story).

We'll be tracking the progression of the ability to perform fully reproducible builds very closely. If any major breakthroughs are made in this area, then we'll be quick to adopt them.

[shesek]

To my knowledge, there's no known way to ensure that builds of Electron-based applications are fully reproducible.

I was able to make reproducible Electron builds of snap and tar.gz for Linux, zip for macOS and exe for Windows.

AppImage appears to have non-determinism in the build process that I couldn't get rid of, and isn't reproducible even on the same host environment. I'm able to reproduce deb on several different environments, but not on others (so almost reproducible, but not quite yet!). Haven't tried dmg builds yet.

This is what I did:

• Build everything inside a Docker container with fixed-version dependencies.

• Reset the chmod attrs of the packed dist files using the afterPack hook.

• Reset the chmod attrs of the entire source directory before building electron. I'm still not sure why its needed exactly and which files specifically need a reset, but it appears like snap builds aren't reproducible without it (the others are).

• Use npm-shrinkwrap to lock-down nodejs dependencies.

• Use libfaketime to set a fixed system clock throughout the electron-builder build process. This, however, introduces two complexities:

  1. When run with faketime, electorn-builder cannot download the artifact files from Github, because the TLS certificates are broken (they appear to come from the future). My solution was to build a dummy app without faketime first, then build the actual app with it. I filed an issue with some more details at Downloading artifacts as a separate step  electron-userland/electron-builder#3220.

  2. libfaketime appears to be break wine, which is required for building exe installers on Linux. My solution was to override the wine executable with one that strips off libfaketime from LD_PRELOAD, then delegates to the original executable.

Cheers!

[Giszmo]

I tried to build the APK for this review. My project currently has rather low standards for reproducible builds but with your wallet I even failed to build it from the Readme.md build instructions. Could you help me get a bit further?

I'd also like to add another argument for why reproducibility matters: The team might have best intentions but under distress, the release manager might build a malicious version and it should be a team's routine to check every release on at least one second machine. The incentives to corrupt a wallet app are just too high to ignore the potential bad guy trying it.

[Giszmo]

3 months went by and no reply? Can we conclude that this wallet is not interested in public scrutiny?

[bolatovumar]

@Giszmo I would wait a bit still since Lightning Labs just hired @jamaljsr as a Lead Frontend Engineer. I'm sure he will sort it out.