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)
When there is a CVE in some JS package, it seems to coincide with an
avalanche of security releases of random other packages.
Dependabot can actually create bulk PRs, let's try those.
Adds a default timeout of 10 seconds for sending notifications so they
don't hang indefinitely. This can happen if the server connected to is
not responding or the case where there's a SIM card in the device, but
it's unactivated so that DNS works but the connection doesn't
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.
It's pretty annoying to have to scroll past all the old recordings to
be able to set the config. Since logs we already have figured out how to
create modals, so let's reuse that code.
Every once in a while, I get the error posted in #901:
Caused by:
0: Failed to send login request
1: error sending request
2: client error (SendRequest)
3: connection closed before message completed
(either this or "failed to start telnet" -- in either case there's a
request happening before it, and it's always "connection closed before
message completed")
Disabling connection pooling seems to reduce the amount of flakiness.
Here is what I used to test this fix:
while echo | cargo run -p installer util orbic-shell --admin-password 96df5476 ; do true; done
Usually it would stop <100 iterations, now it can do 800+ iterations.
This commit introduces checkboxes where users can certify that either
they did not use generative AI to create their pull request, or that
they did but they understand the code and wrote all comments and
descriptions themselves, per our recently publicised open source policy.
This fixes several space-related issues at once.
We have observed the following phenomenon on TP-Link, Orbic and Moxee:
- Filling /data bricks the device (broken wifi, broken rndis, broken
display)
- Filling /cache does not (it only bricks rayhunter if it's installed
there, and it might break firmware updates)
Therefore it would make sense to store the entire rayhunter installation
in /cache.
This is a great idea for TP-Link and Moxee, because /cache is
significantly larger than /data. However, on Orbic, /data is
significantly larger than /cache!
This PR refactors orbic-network and tplink to use a shared codepath for
setting up the data directory. A symlink is created at /data/rayhunter,
and what it points to is device-specific:
- Orbic will have its data at `/data/rayhunter-data`
- There is a new alias `installer moxee` that overrides this to
`/cache/rayhunter-data`
- TP-Link will have its data at /cache/rayhunter-data when there's no SD
card, and /media/whatever when there is one.
In all cases, existing data is migrated to the new location. The user
can switch back and forth between two values of --data-dir and the data
will be moved over every time.
This PR has one huge wart, and that is that the USB installer for Orbic
remains untouched. The annoying reason for this is that the
DeviceConnection trait is insufficient to reflect all the different
kinds of shells you can have over USB: adb with fakeroot, and serial
with real root. I think it's not possible to create the right
directories with 'rootshell -c'.
I'm thinking of spawning a telnet server over serial, so that we can
just do telnet again, but this is for another time.
