We have two versions of rustls-webpki in our deptree:
- One used in the ring backend, which we're upgrading here
- One used in the rustcrypto backend, which we can't upgrade and
therefore have to ignore the CVE anyway.
The ring backend is the one we actually use in release builds.
rustcrypto is only used during development builds to make compilation
simpler.
There is some recent progress on quantum computers being discussed on
HackerNews and lobste.rs, and as a result of that timelines for when PQ
crypto would become essentially mandatory are being adjusted. Example:
https://words.filippo.io/crqc-timeline/
We pretty much have only one place in this entire codebase where any
sort of crypto happens, which is HTTPS for notifications support.
It seems that ring has essentially no plans to support PQ crypto for our
purposes. rustls/rustls#2801briansmith/ring#1685
There's not really a reason to stick with ring, other than that it is a
prod-ready backend. But so is aws-lc-rs, and it seems to be the way
forward if you want PQ crypto today. Maybe that will change again in a
few years.
**The local dev workflow stays the same**, `cargo
build-daemon-firmware-devel` still uses rustcrypto which doesn't require
CC and doesn't have PQ crypto at all. We have no contribution docs for
how to build anything else anyway.
**Implementation:**
This opens a can of worms in building rayhunter-daemon in CI: We're
currently building ring using GCC cross-compilation toolchain from
Debian, which will build ring against **glibc**. Then we take that
library and try to link it against MUSL libc. The reason this works is
because ring's libc usage is very minimal, and the required symbols end
up being just the same as what MUSL libc exposes. The same can't be said
for aws-lc:
```
error: linking with `rust-lld` failed: exit status: 1
= note: rust-lld: error: undefined symbol: __nanosleep64
>>> referenced by urandom.c
>>> urandom.c.o:(do_backoff) in archive
```
So we fix that and link everything we build against MUSL libc (something
we should've done from the start anyway). The problem is that Debian
doesn't ship a MUSL cross-compilation toolchain, and the toolchain
available on https://musl.cc should not be downloaded directly in CI.
Which leaves us with a docker container from messense... That docker
container seems to be extremely popular for cross compilation across
GitHub projects, at least. I couldn't get other options to run reliably
(cross), or they were a too extreme change for my taste (using zig cc)
Currently you have to override a bunch of paths to use firmware-devel
when building the installer. This changes that, and adds a new
FIRMWARE_PROFILE envvar that can be used to fix both rootshell and
rayhunter-daemon paths at the same time.
There is now also a new cargo command for building rootshell, similar to
how building the daemon firmware works.
I'm not sure what to do with make.sh. I have personally never used it.
Support more platforms by using a the soft float musl target for
aarch32/armv7/v8. The installer is not performance bound by floating
point operations.
rustc -C strip=debuginfo leaves the symbol table intact, meaning
RUST_BACKTRACE=1 on the installer still produces helpful output.
This significantly reduces the binary size, eg the amd64 installer goes
from 93M to 21M. Stripping the symbol table only reclaims a further ~2M.
Markus Unterwaditzer