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)
There are no important changes in the new tower version. The only reason
i'm bumping it is because it exposes our mis-configuration of tokio: We
depend on API surface enabled by `io-std`, but don't enable that
feature. Tower 0.5.2 pulls in that feature though, and our code works
anyway. Tower 0.5.3 no longer requires this feature and our code stops
compiling.
...and make a small UI change so that folks won't get concerned about parsing errors.
Right now all the "undecoded extensions" noise goes into
rayhunter-daemon.log, and users get concerned about it when browsing
that through the UI.
These payloads would previous cause panic on underflow.
The fuzzing setup lives in
https://github.com/untitaker/rayhunter/tree/fuzz-wip -- I can eventually
upstream it though right now it runs very inefficiently.
See https://github.com/EFForg/rayhunter/issues/334
Severity levels low, medium, high are now exposed to the UI in form of
dotted, dashed and solid lines. The line on the UI represents the
highest-so-far severity seen.
Originally this was intended to be represented by Yellow/Orange/Red, but
this would mean yet another divergence for colorblind mode. This is
colorblind-friendly by default (I think...)
As part of this, simplify EventType so that it becomes a flat "level"
enum without nested variants.
There is also a new debug endpoint that allows one to overwrite the
display level directly for testing.
Rayhunter uses a mixture of spawn and spawn_blocking, then also does
some blocking operations inside of async code.
Move everything to async. This allows us to use the single-threaded
runtime.
Now the binary is 100kB smaller, and the memory usage also improved by
~100kB on tplink.
