Provide an easy way to verify release binary integrity

[f5b7]

For all binaries I use for staking there's some way to verify the binary's integrity, e.g. a .asc signature file or a sha256 checksum.

I think Nimbus should also provide a way for file verification, to improve its adoption and thus eth2 client diversity.

[stefantalpalaru]

Nimbus should also provide a way for file verification

It already does. Read the "Reproducing the build" section in the "README.md" file that came with your binary archive.

[arnetheduck]

@stefantalpalaru that's a much more complex operation - a sha256 print can be included much more easily in automated verification

[f5b7]

@stefantalpalaru thanks for the hint that there already is a way. I added easy to the subject, to emphasize my intent to improve user experience for better adoption.

@arnetheduck thanks for your comment and the reopening ❤️

[stefantalpalaru]

a sha256 print can be included much more easily in automated verification

We have checksums too, but what's the point of verifying those, if they come through the same channel as the binaries?

When we move from buzzword territory (to "improve adoption") to actual threat modelling, what we need are ways to quickly detect alterations. Not easy ways, but efficient ways.

So far, we have make dist that will recreate our binary release for a certain commit, allowing anyone to verify that no alteration occurred at that point. For source-level alterations, we have Git.

What we can do, after making a new release, is publish the nimbus_beacon_node checksum over non-GitHub channels - social media, chat platforms, etc. It can be easily included in our release blurb, and it shortens the time frame available to an attacker capable of tricking users into downloading an altered binary. It wouldn't affect an attacker having control over GitHub Actions servers, but it's still something.

[dryajov]

The checksum isn't only a means to prevent altering the binary by an attacker, it's also a way of checking that it was correctly transferred over the wire - this is why the checksum is usually provided alongside the executable.

[arnetheduck]

We have checksums too,

right, they are inside the tarball, in the build folder - but it might be a good idea to provide a sum for the tarball itself as well, that is accessible from the releases page (and posted in release notes, twitter etc)

[stefantalpalaru]

The checksum isn't only a means to prevent altering the binary by an attacker, it's also a way of checking that it was correctly transferred over the wire

You wouldn't be able to uncompress the tarball if there was any data corruption. Gzip has an internal checksum.

[f5b7]

What we can do, after making a new release, is publish the nimbus_beacon_node checksum over non-GitHub channels - social media, chat platforms, etc. It can be easily included in our release blurb, and it shortens the time frame available to an attacker capable of tricking users into downloading an altered binary. It wouldn't affect an attacker having control over GitHub Actions servers, but it's still something.

That would be great! With the other binaries (Prysm, Lighthouse, ...) I also would prefer to compare the checksum to one published to another channel than I get the binary from. It just does not feel as reassuring when I get the checksum from the same (possibly compromised) place.

[stefantalpalaru]

We now extract those checksums automatically, during the CI build process, and put them in the release notes.

For distributing them to other channels besides GitHub, @0xmiel is your man.