Raspiblitz: Reproducible SDcard build and community signatures

[openoms]

Would like to try if we can reproduce the SDcard builds and achieve to have more independent signatures like seen at the firmware release of the BitBox02:
https://github.com/digitalbitbox/bitbox02-firmware/blob/firmware-btc-only/v5.0.0/releases/README.md
https://twitter.com/_benma_/status/1206977454935556102

To achieve this will need:

• follow the same procedure as described here: https://github.com/rootzoll/raspiblitz/blob/master/FAQ.md#what-is-the-process-of-creating-a-new-sd-card-image-release (might need to specify the environment versions more) like Ubuntu 18.04, Tails: 4.1.1 etc.
• freeze the versions of all software included in the build_sdcard.sh

[rootzoll]

We can try ... but I dont think it will work. For example the time of all created files in the filesytsem of the sd card will be different on different builds. So the resultung sd image will have always a different checksum.

[openoms]

Agree that making the hash to match is probably out of our scope.
It is difficult enough when done on a binary level where everything is built from the source code only.

There is already an option to build the SDcard with one-line requiring minimal trust: https://github.com/rootzoll/raspiblitz#build-the-sd-card-image , this should be encouraged.

Could it be interesting to compare the size of the manually built images? (built on the same hardware and github commit)

[frennkie]

Wow.. this sounds hard..

I'm wondering whether a sensible step would be to have a list of all files that are on the SD card after a build and check/list their sizes (and maybe sha256 hash) in a file. Then if multiple people do this (and put the signed results somewhere) we could get a baseline against which a not-so-trusting-user could compare his build..?!

[openoms]

Indeed the hashing/signing is unlikely to work, but listing the files and sizes is a good idea. That file containing the list can be signed too.
Would take off some burden of responsibility from @rootzoll if we can confirm the build independently this way and I would be happier reusing the image too ;) .

[rootzoll]

Maybe instead of "Reproducible Builds" take a look at: https://github.com/frankbraun/codechain

[openoms]

@rootzoll This would be about verifying the individual binaries built from source as discussed with Stadicus and Ketominer on the LNConf: https://twitter.com/ketominer/status/1128621759148777473?s=19

[rootzoll]

I was thinking more about signing source code for version releases. At the moment there are 3 admins on the raspiblitz repo - anybody of them can release/tag a version.

[openoms]

Does not git and github comments prove reasonably well that the changes have been reviewed?

I was thinking more about hardening the SDcard release itself to make sure the contents match what is expected from the build script.

Would be in for both.

[frennkie]

In my opinion there is absolutely no way how two separate builds of a RaspiBlitz SD card image with the current setup (executing build_sdcard.sh and then creating the .img file) could result in the same sha256 hash sum!

The reason is that running build_sdcard.sh (even on the same device) later on will at least have different timestamps on each and every file and directory. Additionally there might be changes in debian packages during build1 and build2 (https://github.com/rootzoll/raspiblitz/blob/master/build_sdcard.sh#L131) although this could actually be pinned to certain versions.

For me the main reason for still looking for ways that people could do a verification after they boot the .img file is the following:

• only a very limited number of people have merge/commit rights to this repository
• every change to the repository is publicly visible and can be checked
• BUT when somebody (e.g. @rootzoll) runs the build_sdcard.sh script nobody but him can know that he did not (or did) add another user account, ssh keys or any other kind of backdoor before generating the .img file

Per my idea posted above - if @rootzoll generates a signed list of files and their hashes then @openoms and I could do the same. Then all three of us publish the same list. Anybody who is then in doubt can also run the hash-script on his RaspiBlitz after booting the new .img file and verify that he gets the same results.

I wrote a small hash-script... but with sha256 this took 10 hours to run on my (active) Raspberry Pi 4. I'm now trying another hashing tool for faster generation.

[openoms]

This is great, I agree all above @frennkie.

Question is if the hashing should be done on the RPi at all?

We could build the SDcard release and process it on the desktop just as when the image would be created on the desktop before uploading.

It is an extra step, but anyone can do it after building then SD manually.

Starting to run the setup (and having different ssh keys) would come to different results anyway, the comparison needs to be done in the state just after running the ./XXprepareRelease.sh as described here:
https://github.com/rootzoll/raspiblitz/blob/master/FAQ.md#what-is-the-process-of-creating-a-new-sd-card-image-release