Add GitHub workflow to check that binaries are reproducible.

[gendx]

Fixes #70.

This pull request is the last step for reproducible builds.

• A new reproduce_hashes.sh tool generates reference SHA-256 sums for the OpenSK binaries. These hashes must then be checked in git in the reference_binaries.sha256sum file.
• A new GitHub workflow then compares the cryptographic hashes obtained on continuous integration with those checked into git by the developer. If the hashes don't match, then it means that the builds were not reproducible (although the converse is not necessarily true, this should catch most causes of non-reproducibility).
• Anyone can compare the SHA-256 sums obtained on their machine with those published in git and computed by continuous integration.

---

• Tests pass
• Appropriate changes to README are included in PR

---

Currently blocked on:

• A new release of Tockloader on pip3: New release on pip3? tock/tockloader#58 (related to App object has no attribute get_binary #79).
• Cargo doesn't yield reproducible builds if the host is different: Non-reproducible -C metadata=hash passed to rustc depending on the compiling OS rust-lang/cargo#8140 (also Ignore the host in rustc.verbose_version for metadata rust-lang/cargo#7873). The upstream Cargo issue won't be fixed soon, so for now 2 sets of hashes are provided for reference and checked by GitHub Actions: Linux and MacOS.
• elf2tab is currently not reproducible (Implement a --deterministic mode for reproducibility. tock/elf2tab#16). It stores files into a TAR file, which contains, for each file: a uid, file permissions, a timestamp. The metadata.toml also contains a build timestamp.

[gendx]

For now, this fails for two reasons.

• As mentioned in Sync upstream kernel to get more reproducible builds. #80 (comment), we'll have to use a fixed crypto material for the CTAP2 app to be reproducible.
• For some reason, the binary hashes of the Tock kernel boards are still different on Linux and on MacOS.

[gendx]

This is currently blocked on ./deploy.py --board=$board --opensk --no-tockos --programmer=none, itself blocked on #79 aka tock/tockloader#58.

[gendx]

There is currently a discrepancy between Linux and OSX builds of Tock, despite the --remap-path-prefix parameter. For example, the tock_cells library is built with a different metadata parameter on both platforms (whereas I've observed it to be the same on the workflow's Linux machine and on my own Linux machine).

• On Linux (https://github.com/google/OpenSK/pull/94/checks?check_run_id=602439620): rustc --crate-name tock_cells libraries/tock-cells/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=z -C panic=abort -C debuginfo=2 -C metadata=92487154152022d3 -C extra-filename=-92487154152022d3 --out-dir /home/runner/work/OpenSK/OpenSK/third_party/tock/target/thumbv7em-none-eabi/release/deps --target thumbv7em-none-eabi -L dependency=/home/runner/work/OpenSK/OpenSK/third_party/tock/target/thumbv7em-none-eabi/release/deps -L dependency=/home/runner/work/OpenSK/OpenSK/third_party/tock/target/release/deps -C link-arg=-Tlayout.ld -C linker=rust-lld -C linker-flavor=ld.lld -C relocation-model=dynamic-no-pic -C link-arg=-zmax-page-size=512 -C link-arg=-icf=all --remap-path-prefix=/home/runner/work/OpenSK/OpenSK/third_party/tock/= -D warnings
• On OSX (https://github.com/google/OpenSK/pull/94/checks?check_run_id=602439631): rustc --crate-name tock_cells libraries/tock-cells/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=z -C panic=abort -C debuginfo=2 -C metadata=9fc982d890c0358d -C extra-filename=-9fc982d890c0358d --out-dir /Users/runner/runners/2.169.0/work/OpenSK/OpenSK/third_party/tock/target/thumbv7em-none-eabi/release/deps --target thumbv7em-none-eabi -L dependency=/Users/runner/runners/2.169.0/work/OpenSK/OpenSK/third_party/tock/target/thumbv7em-none-eabi/release/deps -L dependency=/Users/runner/runners/2.169.0/work/OpenSK/OpenSK/third_party/tock/target/release/deps -C link-arg=-Tlayout.ld -C linker=rust-lld -C linker-flavor=ld.lld -C relocation-model=dynamic-no-pic -C link-arg=-zmax-page-size=512 -C link-arg=-icf=all --remap-path-prefix=/Users/runner/runners/2.169.0/work/OpenSK/OpenSK/third_party/tock/= -D warnings

I'll report it upstream to Tock and Rust.

[gendx]

It seems that Rust builds won't be reproducible across hosts for the time being (rust-lang/cargo#8140). Until then, setting up two reference files for the SHA-256 hashes.

[jmichelp]

Should we do like in the tock-on-titan project and symlink the rust-toolchain from the kernel at the app level so that we use the same version?

[gendx]

Should we do like in the tock-on-titan project and symlink the rust-toolchain from the kernel at the app level so that we use the same version?

Definitely! This would also reduce the time wasted by the workflows to install various versions of the compiler, and therefore reduce the likelihood of being cancelled by the GitHub runner.

[gendx]

With elf2tab 0.5.0 published on crates.io, this pull request is now unblocked.

[jmichelp]

What's going to be the process to keep these hashes up-to-date?
They're going to change on pretty much every merged PR and waiting for the workflow to fail in order to grab the correct hashes for both platforms and then update the PR with it is not the most friendly workflow IMHO.

[gendx]

What's going to be the process to keep these hashes up-to-date?
They're going to change on pretty much every merged PR and waiting for the workflow to fail in order to grab the correct hashes for both platforms and then update the PR with it is not the most friendly workflow IMHO.

One should be able to run the ./reproduce_hashes.sh script locally to update the hashes on the platform they use. Unfortunately, one still needs to check the workflow for other platforms until rust-lang/cargo#8140 is fixed.

Maybe we can leave this workflow as non required until then? And for example only update hashes after all the reviews have been resolved on a pull request.

[jmichelp]

Ok, let's merge it like this and revisit later when we need to run the workflow.
Maybe we need to move to a stable vs. dev branches where reproducibility needs to be run only on stable branch. The other option I have in mind is to modify the workflow: instead of checking hashes, it can publish them.

[gendx]

The other option I have in mind is to modify the workflow: instead of checking hashes, it can publish them.

This would be a good idea too (although wouldn't catch regressions in reproducibility). The current workflow already uploads the reproduced binaries, so it wouldn't be hard to upload the expected hashes in there, or to print them in the workflow's console output.