mirror of
https://github.com/EFForg/rayhunter.git
synced 2026-04-27 07:59:59 -07:00
dc1d193b8e
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#2801 briansmith/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)
47 lines
1.6 KiB
TOML
47 lines
1.6 KiB
TOML
[package]
|
|
name = "rayhunter-daemon"
|
|
version = "0.10.2"
|
|
edition = "2024"
|
|
rust-version = "1.88.0"
|
|
|
|
[lib]
|
|
name = "rayhunter_daemon"
|
|
path = "src/lib.rs"
|
|
|
|
[[bin]]
|
|
name = "gen_api"
|
|
path = "src/bin/gen_api.rs"
|
|
required-features = ["apidocs"]
|
|
|
|
[features]
|
|
default = ["rustcrypto-tls"]
|
|
rustcrypto-tls = ["reqwest/rustls-tls-webpki-roots-no-provider", "dep:rustls-rustcrypto"]
|
|
pq-tls = ["reqwest/rustls-tls-webpki-roots-no-provider", "dep:rustls-post-quantum"]
|
|
apidocs = ["dep:utoipa"]
|
|
|
|
[dependencies]
|
|
rayhunter = { path = "../lib" }
|
|
toml = "0.8.8"
|
|
serde = { version = "1.0.193", features = ["derive"] }
|
|
tokio = { version = "1.44.2", default-features = false, features = ["fs", "signal", "process", "rt"] }
|
|
axum = { version = "0.8", default-features = false, features = ["http1", "tokio", "json"] }
|
|
thiserror = "1.0.52"
|
|
libc = "0.2.150"
|
|
log = "0.4.20"
|
|
tokio-util = { version = "0.7.10", features = ["rt", "io", "compat"] }
|
|
futures-macro = "0.3.30"
|
|
include_dir = "0.7.3"
|
|
chrono = { version = "0.4.31", features = ["serde"] }
|
|
tokio-stream = { version = "0.1.14", default-features = false, features = ["io-util"] }
|
|
futures = { version = "0.3.30", default-features = false }
|
|
serde_json = "1.0.114"
|
|
image = { version = "0.25.1", default-features = false, features = ["png", "gif"] }
|
|
tempfile = "3.10.2"
|
|
async_zip = { version = "0.0.17", features = ["tokio"] }
|
|
anyhow = "1.0.98"
|
|
reqwest = { version = "0.12.20", default-features = false }
|
|
rustls-rustcrypto = { version = "0.0.2-alpha", optional = true }
|
|
rustls-post-quantum = { version = "0.2.4", optional = true }
|
|
async-trait = "0.1.88"
|
|
utoipa = { version = "5.4.0", optional = true }
|