docs/LINUX.md lists this as the one unverified assumption the Linux backend rests on:
Whether ARC Raiders under Proton honors SSLKEYLOGFILE for the connection ARCTracker reads has not been verified end-to-end on this machine [...] If keys aren't written, no decryption is possible regardless of capture.
It is honored, and a full sync completes on Linux. Setup: CachyOS, kernel 7.1.6, Wayland, Proton cachyos-11.0-20260703-slr, ARC Raiders on Steam, built from d591460.
Three checks, rather than trusting a green screen:
lsof on the key log shows the game's own GameThread holding write descriptors on it, so PioneerGame.exe writes to the file itself rather than something upstream of it doing so on its behalf. Proton's python3 wrapper and wineserver hold descriptors too, and the header line is CPython's — which of them wrote any given secret was not established, only that the game is among the writers.- The file accumulates TLS 1.3 secrets —
CLIENT_HANDSHAKE_TRAFFIC_SECRET, SERVER_TRAFFIC_SECRET_0, and so on — and keeps growing across a session.
- With capture running, the app reached its synced state and named the ARCTracker account.
One caveat worth documenting: capture only decrypts handshakes it witnesses, so the app has to be started before the game. If the game is already running it must be restarted, otherwise the gateway handshake is missed and the app sits on "looking for your account" indefinitely. This is the single easiest symptom to mistake for a bug.
While getting there I ran into a handful of separate issues, all with fixes ready if you want them as PRs:
cargo clippy --all-targets -- -D warnings, exactly as CI runs it, fails on current stable rustc (1.97.1) with 32 instances of falling back to f32 as the trait bound f32: From<f64> is not satisfied. I hit this on the Linux job; the Windows one runs the same command and 27 of the 32 are in theme.rs and widgets.rs, which carry no cfg(windows) at all.i18n::tests::unknown_tag_resolves_to_english fails on any machine whose system locale is supported and not English — it falls through to the system language. Reproduces with LANG=es_ES.UTF-8 cargo test --lib i18n.- The Linux CI job and the README install
libgtk-3-dev, libxdo-dev, libayatana-appindicator3-dev and pkg-config; a release build and cargo test both complete in a container with none of them present.
find_processes cannot see a Wine process, so game_running is permanently false on Linux: /proc/<pid>/exe resolves to the Wine preloader and comm holds the main thread's name (ARC Raiders reports GameThread).- File dialogs never open once the binary carries
CAP_NET_RAW, which scripts/run-linux.sh grants by default — xdg-desktop-portal cannot identify the caller, so pick_file() returns None and both "choose game" buttons look inert.
launcher_readiness reads SSLKEYLOGFILE from the launcher process, which misses Steam's per-game launch options entirely — they reach the game and never the Steam process. Happy to open a separate issue for that one, since it is a behaviour change rather than a fix.
Glad to send any subset as PRs, or none at all if you would rather take a different approach.
docs/LINUX.mdlists this as the one unverified assumption the Linux backend rests on:It is honored, and a full sync completes on Linux. Setup: CachyOS, kernel 7.1.6, Wayland, Proton
cachyos-11.0-20260703-slr, ARC Raiders on Steam, built fromd591460.Three checks, rather than trusting a green screen:
lsofon the key log shows the game's ownGameThreadholding write descriptors on it, soPioneerGame.exewrites to the file itself rather than something upstream of it doing so on its behalf. Proton'spython3wrapper and wineserver hold descriptors too, and the header line is CPython's — which of them wrote any given secret was not established, only that the game is among the writers.CLIENT_HANDSHAKE_TRAFFIC_SECRET,SERVER_TRAFFIC_SECRET_0, and so on — and keeps growing across a session.One caveat worth documenting: capture only decrypts handshakes it witnesses, so the app has to be started before the game. If the game is already running it must be restarted, otherwise the gateway handshake is missed and the app sits on "looking for your account" indefinitely. This is the single easiest symptom to mistake for a bug.
While getting there I ran into a handful of separate issues, all with fixes ready if you want them as PRs:
cargo clippy --all-targets -- -D warnings, exactly as CI runs it, fails on current stable rustc (1.97.1) with 32 instances offalling back to f32 as the trait bound f32: From<f64> is not satisfied. I hit this on the Linux job; the Windows one runs the same command and 27 of the 32 are intheme.rsandwidgets.rs, which carry nocfg(windows)at all.i18n::tests::unknown_tag_resolves_to_englishfails on any machine whose system locale is supported and not English — it falls through to the system language. Reproduces withLANG=es_ES.UTF-8 cargo test --lib i18n.libgtk-3-dev,libxdo-dev,libayatana-appindicator3-devandpkg-config; a release build andcargo testboth complete in a container with none of them present.find_processescannot see a Wine process, sogame_runningis permanently false on Linux:/proc/<pid>/exeresolves to the Wine preloader andcommholds the main thread's name (ARC Raiders reportsGameThread).CAP_NET_RAW, whichscripts/run-linux.shgrants by default —xdg-desktop-portalcannot identify the caller, sopick_file()returnsNoneand both "choose game" buttons look inert.launcher_readinessreadsSSLKEYLOGFILEfrom the launcher process, which misses Steam's per-game launch options entirely — they reach the game and never the Steam process. Happy to open a separate issue for that one, since it is a behaviour change rather than a fix.Glad to send any subset as PRs, or none at all if you would rather take a different approach.