mirror of
https://github.com/therealaleph/MasterHttpRelayVPN-RUST.git
synced 2026-05-18 07:34:36 +03:00
ae948f4075ed8a55f6584f5b87aa477a7aa0703d
71 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 therealaleph
|
ae948f4075 |
v1.7.1: ship cert removal (#121)
mhrv-rs --remove-cert (CLI) and Remove CA button (UI) for verified clean-slate revocation. Clears OS trust store, NSS browser stores (Linux Firefox/Chrome), and the on-disk ca/ directory. config.json and the Apps Script deployment are untouched. By-name trust verification runs before browser-state mutation; OS removal failures return RemovalIncomplete with browser state intact so retries are idempotent. Sudo-aware on Unix (re-roots HOME to the real user). 29 new unit tests on the pure logic (Firefox user.js marker handling, getent passwd parsing, NSS stderr classification, NssReport state rules). Tested end-to-end on Windows by the contributor; macOS verified at merge time on real hardware (login keychain delete + NSS-missing fallback). Linux paths await user testing. Closes #121. Thanks @dazzling-no-more. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
therealaleph
|
6469e1fd44 |
v1.7.0: native udpgw, Android UI restructure, release tooling
Highlights: - Native udpgw protocol in Full mode (#222) — Telegram voice/video calls and Google Meet now work in Full mode on Android. UDP flows through one persistent TCP tunnel (instead of session-per-destination) so STUN/RTP flow counts no longer stall. Requires redeploying the tunnel-node Docker image (ghcr.io/therealaleph/mhrv-tunnel-node:1.7.0). - Android home screen restructure (#258, closes #246) — Connect button now pinned under Mode field, App picker shows pre-selected apps at top. With long deployment-ID lists, Connect no longer scrolls off-screen. - release-drafter + prepare-release tooling (#260) — incrementally drafts release notes from merged PR titles; manual workflow_dispatch prepares version bumps + changelog stubs. No protocol breaking changes; existing apps_script-mode and Full-mode deployments work unchanged. Full-mode users get udpgw automatically once the tunnel-node Docker image is updated. Thanks to @yyoyoian-pixel and @dazzling-no-more. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
yyoyoian-pixel
|
1057797109 |
feat: native udpgw without QUIC/DNS - QUIC/DNS with udp associate — stable VoIP, faster browsing - needs new tunnel deployment for udpgw (#222)
* feat: native udpgw protocol alongside existing UDP associate Why udpgw is needed even with UDP associate: UDP associate (udp_open/udp_data) creates one tunnel session per UDP destination and polls each independently. On high-latency or shaky networks this compounds — N simultaneous UDP flows need N separate polling loops, each paying its own batch round-trip overhead. Google Meet calls, which fire dozens of concurrent STUN + RTP flows, stall or fail entirely because the per-destination polling can't keep up. udpgw multiplexes ALL UDP over one persistent TCP-like session using conn_id framing. One batch op carries frames for many destinations. Persistent sockets per (conn_id, dest) with continuous reader tasks keep source ports stable — critical for protocols like Telegram VoIP and STUN that expect replies on the same port. Both paths coexist — they serve different traffic: - UDP associate (SOCKS5): apps that negotiate SOCKS5 UDP relay - udpgw (198.18.0.1:7300): TUN-captured UDP (DNS, QUIC, Meet, etc.) tun2proxy vendored as git submodule at v0.7.20 with one transparent commit adding udpgw_server to the Android JNI run() function. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: block QUIC (UDP 443) and DNS (UDP 53) from udpgw QUIC through udpgw is slower than TCP/HTTP2 through the batch pipeline — blocking it forces browsers to fall back to TCP, improving YouTube and general browsing speed. DNS is better handled by tun2proxy's virtual DNS / SOCKS5 UDP associate path which is more reliable for single request-response exchanges. VoIP (Telegram, Meet) still flows through udpgw normally. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: replace submodule with [patch.crates-io] for tun2proxy udpgw Use the idiomatic Rust [patch.crates-io] mechanism instead of a git submodule. Points to yyoyoian-pixel/tun2proxy fork with the udpgw JNI parameter patch (upstream PR: tun2proxy/tun2proxy#247). Will be removed once upstream ships the change in tun2proxy >= 0.8. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: pin tun2proxy patch SHA in Cargo.lock Locks tun2proxy at dfc24ed1 so the patch resolution is recorded and any branch rewrite is visible in the lockfile diff. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: use AbortHandle for ConnSocket readers to prevent FD leaks JoinHandle::drop detaches the task without aborting it. When udpgw_server_task is cancelled (session close), the post-loop cleanup never runs and per-(conn_id, dest) reader tasks become zombies holding Arc<UdpSocket> file descriptors. AbortHandle::drop aborts the task automatically, so cleanup is correct by construction regardless of how the parent task exits. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: yyoyoian-pixel <279225925+yyoyoian-pixel@users.noreply.github.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> |
||
|
therealaleph
|
465c31cfa5 |
v1.6.5: bundles 4 community PRs
- #245 (@Parsa307): match twitter.com in X.com URL normalization - #255 (@dazzling-no-more): copy-logs button + selectable log lines on Android - #257 (@dazzling-no-more): bulk paste of multiple deployment IDs on Android - #256 (@dazzling-no-more): plain HTTP proxy passthrough in google_only mode (used to return 502; now falls through to direct TCP / upstream_socks5, matching the existing CONNECT behavior) No protocol or wire-format changes; existing config and Apps Script deployments work unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
therealaleph
|
b030aaf454 |
v1.6.4: fix Full-mode L7 muxer not batching ops (#231)
The batch-build loop blocked on a 30 ms timeout for the first message, then drained whatever else was in the channel via try_recv() and fired the batch. Under any non-bursty workload, the channel queue was always empty by the time the first op woke us up — so every "batch" had exactly one op, defeating the entire batching premise. Reporter (w0l4i) saw `batch: 1 ops → ..., rtt=6.3 s` repeating in logs even under high concurrency. Fix: after the first op lands, hold the buffer open for an 8 ms coalescing window. Concurrent ops (parallel fetches, HTTP/2 stream openings, etc.) now accumulate into the same batch. 8 ms is rounding error against the 2–7 s Apps Script RTT we're amortizing, and restores the multi-op-per-batch behavior the rest of the code already supports (MAX_BATCH_OPS=50, MAX_BATCH_PAYLOAD_BYTES=4 MiB). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
therealaleph
|
2c8fcc75aa |
v1.6.3: fix Android notification SOCKS5 port mismatch (#211)
buildNotif() hardcoded `proxyPort + 1` for the SOCKS5 line, ignoring cfg.socks5Port entirely. With the default Android config (listenPort=8080, socks5Port=1081) the foreground notification read "Routing via SOCKS5 127.0.0.1:8081" but the real listener was on 1081 — so users configuring per-app SOCKS5 (Telegram, etc.) against the notification value silently failed. Use the same `cfg.socks5Port ?: (cfg.listenPort + 1)` elvis fallback the real listener uses, and surface both ports in the notification: HTTP 127.0.0.1:8080 · SOCKS5 127.0.0.1:1081 Reported by vpnineh and l3est (with netstat screenshots showing the exact mismatch). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
therealaleph
|
3f014b003b |
v1.6.2: fix "every download capped at 256 KB" (fix #162)
In `relay_parallel_range`, when a chunk failed validation (`extract_exact_range_body` returned Err) OR the stitched body length didn't match the advertised total, the fallback path called `rewrite_206_to_200(&first)` — which converted the 256 KiB probe response into HTTP 200 + Content-Length=262144 and returned that as if it were the full file. Browsers saw a complete-looking 200 and treated the download as finished at 256 KB. Common triggers for the chunk-validation failure (per the user reports): - Apps Script's UrlFetchApp stripping `Content-Range` from chunk responses while preserving it on the probe - Origin returning 200-OK on follow-up Range requests (some servers flatten ranges after the first one) - Mismatched `total` field across chunks for paths behind a varying cache layer The correct fallback is a single GET without any Range header — Apps Script fetches the whole URL (up to its 50 MiB cap) and returns a normal 200 with the complete body. Slower than parallel for large files but produces a correct response, which is the minimum bar. Two independent reports (Ehsan in #162, Recruit1992 confirming). 98 lib tests still pass; existing `validate_probe_range_rejects_*` and `extract_exact_range_body_*` tests already cover the validation side, the fallback path is observed integration-testing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
therealaleph
|
14e7dfc7d7 |
v1.6.1: Android VPN session lifecycle reliability (#187)
Five small but real Android-only fixes: 1. Connect/Disconnect button gated on VpnState.isRunning state-flow with 12s backstop, replacing the fixed 2s transitionCooldown timer. Closes the race where a tap-after-Stop hit "Address already in use" because the previous teardown's listener-socket release wasn't done. 2. Tun2proxy.stop() wrapped in 2s join() — if the native call hangs, bounded teardown still releases the listener port instead of holding the teardown thread. 3. fd-leak fixed between parcelFd.detachFd() and Thread.start(): an OOM-thrown Thread.start used to orphan the detached fd. Now adopted into a fresh ParcelFileDescriptor purely so we can close() it. 4. Misleading teardown doc-comment rewritten — the "step 2 closes the TUN fd to force EBADF on read" claim has been factually wrong since detachFd landed. 5. Recursive crash trap: Log.e in MhrvApp's uncaught handler now wrapped in try/catch so a logd failure during exception logging falls through to the previous handler with the real exception. No Rust changes; 98 lib + 22 tunnel-node tests still pass. Local Android build verified, APK installed on mhrv_test emulator, launches cleanly with v1.6.1 in title. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
therealaleph
|
1b22dce568 |
v1.6.0: end-to-end UDP support in Full Tunnel mode
Ships PR #183. SOCKS5 UDP ASSOCIATE → tunnel-mux udp_open/udp_data ops → tunnel-node UDP sessions → real UDP egress. QUIC/HTTP3, DNS, and STUN now traverse the tunnel instead of falling back to TCP or leaking outside it. - 256-session-per-associate cap with FIFO eviction - 9 KB datagram size guard (DNS/STUN tiny, QUIC max ~1452, leaves IPv6 PMTUD headroom without burning Apps Script quota on rogue traffic) - Source-IP pinned to the control TCP peer; port locked to first parseable datagram (malformed datagrams from the right IP no longer DoS the legitimate flow) - Event-driven UDP drain reusing v1.5.0's long-poll knobs Backward compat: TunnelResponse.pkts is `Option<Vec<String>>` with serde default; v1.5.0 clients hitting v1.6.0 tunnel-nodes ignore the new field; v1.6.0 clients hitting v1.5.0 tunnel-nodes get UNSUPPORTED_OP on udp_open and the existing fallback path takes over (TCP-only). Apps Script CodeFull.gs is opaque to the new ops — no redeploy needed; just doc-comment update. 98 lib tests + 22 tunnel-node tests pass (was 92 + 17 before). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
therealaleph
|
fb552c227d |
v1.5.0: long-poll Full Tunnel + Docker tunnel-node + brief FA release notes
Ships PR #173 (event-driven drain) plus three operational improvements: PR #173 — long-poll tunnel mode. The tunnel-node's batch drain switched from a fixed 150 ms sleep to an event-driven Notify wait; idle sessions long-poll up to 5 s and wake on the first byte from upstream. Push notifications and chat messages now arrive in roughly RTT instead of waiting for the next client poll tick. Backward compat with pre-#173 tunnel-nodes is automatic via a sticky AtomicBool that detects fast empty replies and reverts to the legacy cadence. 92 client tests + 17 tunnel-node tests pass, including end-to-end TCP-pair verification of the notify wiring. Docker image for tunnel-node. Adds a hardened Dockerfile (BuildKit cache mounts, non-root runtime user, ca-certificates for HTTPS upstreams) and a .dockerignore to keep build context small. New `tunnel-docker` job in the release workflow builds + pushes multi-arch (linux/amd64 + linux/arm64) to ghcr.io/therealaleph/mhrv-tunnel-node with `:latest`, `:1.5`, and `:1.5.0` tags on every release. Setting up Full Tunnel mode goes from "rustup + cargo build on a 1 GB VPS" (which fails on memory half the time) to a one-liner. tunnel-node/README.md updated with prebuilt-image + docker-compose recipes. Brief Persian release note in Telegram caption. The release-post caption now leads with a `<blockquote>`-wrapped FA bullet headlines extracted from `docs/changelog/v<ver>.md`, above the existing two links (repo + release). Markdown links → Telegram HTML <a> for clickability. Cap-budget-aware truncation at bullet boundaries keeps total caption under Telegram's 1024-char limit. Headlines-only rather than full bullets so multiple "what's new" items fit comfortably (the full bullets remain on the GH release page and as the optional --with-changelog reply-threaded message). GitHub Releases page bodies now lead with the changelog content (Persian section + `---` + English) instead of just a Full Changelog comparison link. The auto comparison link is appended at the bottom via `append_body: true` rather than removed. Workflow changes: - New `permissions: packages: write` at the workflow level (required for ghcr push via docker/login-action). - New `tunnel-docker` job needs `build` (not the full matrix) to serialize the QEMU buildx layer with the matrix cache. - Release job composes the body from `docs/changelog/v${VER}.md` in a pre-step that handles both tag-push and workflow_dispatch paths (uses inputs.version || github.ref_name like the rest of the workflow). Tested locally: - `cargo test` — 92 lib tests pass - `cargo test -p mhrv-tunnel-node` — 17 tests pass - `docker build` of tunnel-node Dockerfile — 32 MB image, runs as non-root, /health returns "ok", auth rejection works correctly, legitimate requests open sessions to remote hosts - Telegram script `--dry-run` mode added; rendered captions for v1.4.0, v1.4.1, v1.5.0 all fit under 900 chars Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
therealaleph
|
17addeda06 |
v1.4.1: Test Relay aware of Full mode + ship missing mipsel artifact
Patch release covering:
- #160 (deniz_us): Test Relay returned Google datacenter IPs even in
Full Tunnel mode, because test_cmd::run unconditionally used
fronter.relay() (apps_script path) regardless of configured mode.
The user's tunnel-node was actually working — whatismyipaddress.com
in their browser showed the correct VPS IP — but Test Relay
contradicted it. Now Test Relay refuses cleanly in Full mode with
a clear message and points users at the right verification path.
A real Full-mode test through the tunnel mux is enhancement-tracked.
- mhrv-rs-openwrt-mipsel-softfloat artifact lands natively (commit
|
||
|
therealaleph
|
8221d4280b |
v1.4.0: connect_data RTT win, Android ONLY-mode edge case, range-cap
Rolls up #150 + #151 + #153 (all merged on main) into a tagged release. Highlights: - Full Tunnel mode opens new HTTPS connections ~500-2000 ms faster (#153). The new connect_data tunnel op bundles the client's first bytes (typically TLS ClientHello) with the CONNECT call, eliminating one full Apps Script round trip per new flow. Backward compat is handled via UNSUPPORTED_OP detection + sticky AtomicBool fallback + pending_client_data replay so older deployments keep working without byte loss. New `connect_data preread: X win / Y loss / Z skip` metric in logs lets us measure the win ratio empirically. - Android ONLY-mode split fix (#150): when the allow-list contained only mhrv-rs or stale uninstalled packages, every addAllowedApplication call silently failed and Android applied the TUN to every app — looping our own proxy traffic. Now we count successful adds; if zero, we fall back to ALL-mode self-exclusion. Complements PR #143 which fixed the empty-list case. - Memory-safety cap on relay range stitching (#151): a hostile or buggy origin could advertise an absurd Content-Range total (e.g. 10 GiB) and force range-parallel to plan millions of chunks and preallocate a huge stitched buffer. Now capped at 64 MiB; larger totals fall back to a normal single GET. Tests: 91 lib tests pass (was 82; +1 from #151, +8 from #153). Tunnel-node: 6 tests pass (all new from #153). Local Android build verified — universal + four per-ABI APKs all produced at expected sizes (universal 53 MB, arm64-v8a 21 MB, armeabi-v7a 18 MB, x86_64 23 MB, x86 22 MB). Installed on mhrv_test emulator, app launches and renders correctly with v1.4.0 in title. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
therealaleph
|
5bb26a4961 |
v1.3.0: per-deployment concurrency, ABI-split APKs, ONLY-mode fix
Rolls up the four post-v1.2.14 commits on main into a single tagged release. Highlights: - Per-deployment concurrency (#142): each deployment ID gets its own 30-permit semaphore, so setups with deployments across multiple Google accounts get a genuine 30×N throughput ceiling. Single-account setups still cap at Google's per-account 30-simultaneous limit — docs (EN + FA) updated to call that out. - Android app-splitting ONLY-mode bug fix (#143): the previous code called both addAllowedApplication and addDisallowedApplication, which Android documents as mutually exclusive. ONLY mode was silently failing establish(). Now fixed. - Per-ABI Android APKs (#136): ships four split APKs (arm64-v8a ~21 MB, armeabi-v7a ~18 MB, x86_64 ~23 MB, x86 ~22 MB) alongside the ~53 MB universal. Huge distribution win for users on unreliable censorship-tunnel paths — the 21 MB arm64-v8a download succeeds where the universal doesn't. - Honest IP-exposure note in Security Posture (#148): clarified that v1.2.9's forwarded-header stripping only covers the client-side leg; what Google's own infrastructure may add on the UrlFetchApp.fetch() second leg is outside this client's control. Full Tunnel mode is the recommendation for threat models where that matters. - Telegram release-post format: added Persian preambles above both links (GitHub repo + full Persian guide; release page + desktop/ router builds) so channel readers see the intent at a glance. 82 tests pass. Desktop + Android builds both verified clean locally across the v1.2.15+ commit series. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
therealaleph
|
d01e9f0f2f |
v1.2.14: Usage today (estimated) card + Persian guide localization
Adds a daily-budget visualization for users worried about hitting the
Apps Script free-tier quota (20,000 UrlFetchApp calls/day).
Usage today card (desktop + Android):
- today_calls / today_bytes / today_key / today_reset_secs atomics on
DomainFronter, hooked into the bytes_relayed fetch_add path so we only
count successful relays (matching what Google actually billed)
- Daily rollover at 00:00 UTC, std-only date math (Hinnant's
civil_from_days) — no chrono/time dep pull
- StatsSnapshot extended with the four new fields + to_json() for the
Android JNI bridge
- Desktop UI renders the card right under the existing Traffic stats
with a hyperlink to https://script.google.com/home/usage for the
authoritative Google-side number
- Android UI renders the same card via Compose, polling
Native.statsJson(handle) once a second only while the proxy is up,
with an Intent(ACTION_VIEW, …) opening the dashboard URL
JNI / state plumbing:
- New Java_…_statsJson reads the Arc<DomainFronter> kept in slot_map
- VpnState.proxyHandle StateFlow so HomeScreen knows which handle to
poll without poking into the service's internal state
- MhrvVpnService publishes the handle on start, zeroes on teardown
Persian localization:
- HowToUseBody (5-step guide + Cloudflare Turnstile note) was
hardcoded English even when locale=FA. Ported to a string resource
with a full FA translation in values-fa/strings.xml. Persian users
no longer drop to English at the bottom of the screen.
Also lands the deferred Android ConfigStore.kt wiring for
passthrough_hosts (commit
|
||
|
therealaleph
|
a05fc5d612 |
v1.2.13: Android Full Tunnel Mode requires credentials (fix #124)
Bug fix release. My v1.2.12 merge of Mode::Full bypassed the deployment-ID + auth-key check on Android, but Full mode talks to CodeFull.gs on Apps Script and needs those same credentials. Users selecting "Full tunnel (no cert)" with empty fields would see the VPN service bail silently instead of surfacing a clear "config incomplete" error. Vahidlazio's fix changes the gate from `mode == APPS_SCRIPT` to `mode != GOOGLE_ONLY` and removes the Mode.FULL bypass in the Start button's enabled-state. Also includes a UX refactor of the Deployment IDs editor (per-row rows with add/remove buttons instead of raw newline-separated text), making multi-deployment setups easier to manage on Android — useful now that Full Tunnel Mode users routinely scale to 5+ deployments per their Google accounts. Android-only diff; Rust side is byte-identical to v1.2.12. |
||
|
therealaleph
|
9e2b8e5f3e |
v1.2.12: Full Tunnel Mode (#94 merged)
Rollup of PR #94 — Mode::Full dispatch + batch tunnel client. Ships the long-awaited no-MITM path that was the motivating fix for half the open issues this week. User-facing: add `"mode": "full"` to config.json, deploy CodeFull.gs as a second Apps Script alongside your existing one, deploy tunnel-node (tunnel-node/README.md) on a VPS, and traffic is tunneled end-to-end: client → mhrv-rs → script.google.com → your tunnel node → destination. Browser speaks TLS directly with the destination; we never see plaintext. No CA needed on the client device. Android side gets a "Full tunnel (no cert)" dropdown option; toggling it writes `"mode": "full"` to config.json. Safety: Mode::AppsScript and Mode::GoogleOnly dispatch paths are unchanged — Full mode is an additive branch at the top of dispatch_tunnel. Existing users on the default apps_script mode see zero behaviour change. Testing status: compiles clean on all 10 CI targets; 75 tests pass (+2 new config-validation tests for Full mode); end-to-end real-VPS testing will come post-release from @Feiabyte and others who opt in. Any Full-mode regression gets a fast-follow fix. |
||
|
therealaleph
|
259431b44f |
v1.2.11: x.com URL truncation now fires for www.x.com (fix #64)
Single-bug release. Unblocks x.com browsing for users whose browsers resolve to www.x.com rather than bare x.com — i.e. essentially everyone using Firefox / Chrome / Safari. Previous releases still advertised the URL-truncation fix as working but it only matched exact Host: x.com, which never happens in real traffic. v1.2.11 widens the matcher to x.com + *.x.com so www.x.com, api.x.com, and any future x.com subdomain all get the shortened URL through Apps Script's URL length cap. |
||
|
therealaleph
|
29777ce5b2 |
v1.2.10: proxy Stop actually stops now (fix issue #99)
Single-focus release. The Stop button in the UI previously only
stopped new connections from being accepted — in-flight clients kept
running on the old DomainFronter, which meant:
- Pages kept loading after Stop (users thought they'd stopped)
- Auth-key changes didn't take effect for domains with a live
keep-alive to the proxy
- Apps Script quota could still be consumed post-Stop
Fix (
|
||
|
therealaleph
|
1d2eb19295 |
v1.2.9: fix UI build for youtube_via_relay (v1.2.8 CI abandoned)
v1.2.8 tagged cleanly but CI failed compiling mhrv-rs-ui with:
error[E0063]: missing field `youtube_via_relay` in initializer of
`mhrv_rs::config::Config`
When I added the youtube_via_relay field to the main Config struct
in
|
||
|
therealaleph
|
6fdbfe3966 |
v1.2.8: real-IP-leak fix + youtube_via_relay + scan_sni hardening
Rollup of four merged fixes since v1.2.7: - security: strip identity-revealing forwarding headers in the Apps Script relay path. Closes the XFF leak vector from issue #104 — users chained behind xray/v2rayNG or running browser extensions that inject X-Forwarded-For / Forwarded / Via / CF-Connecting-IP etc. would previously have those forwarded to the origin via the relay. Now stripped to 16 header variants with a regression test. - proxy: new `youtube_via_relay` config toggle (#102). Routes YouTube family suffixes through Apps Script instead of the SNI-rewrite tunnel. Trades SafeSearch-on-SNI for Apps Script's fixed User-Agent + quota cost. Off by default. - scan_sni: decode chunked dns.google DoH responses (#97, from @freeinternet865). Without this, PTR lookups always failed and scan-sni discovered zero domains. - scan_sni: verify dns.google TLS with webpki roots (#98, from @freeinternet865). The DoH request is a normal public HTTPS call — an on-path MITM should not be able to forge PTR answers and poison the suggested SNI pool. 73 tests pass (up from 67 — three new chunked-decode tests + one XFF-filter + two youtube_via_relay branches). |
||
|
therealaleph
|
0a29cf0740 |
v1.2.7: SNI cert fix mirrored to Android + tunnel-node scaffold (via #92 + #93)
- Android DEFAULT_SNI_POOL: mirror the Rust-side fix from #92 — accounts.googl.com replaced by accounts.google.com. Same cert-SAN mismatch that was failing every Nth rotation in the Rust client affected the Android user's sniHosts population; both pools need to stay in sync by design. - Release rolls up PR #92 (cert fix) and PR #93 (tunnel-node + CodeFull.gs scaffolding). PR #93 adds a standalone binary under tunnel-node/ plus an Apps Script companion; no main-crate changes, so this is a zero-risk merge. Users who want to deploy a tunnel node can start today. The dispatch that activates `mode: full` is still in review in PR #94. |
||
|
therealaleph
|
658e72fe0d |
v1.2.6: rust-cache bin pruning fix + PR #83 scan-sni
v1.2.4 and v1.2.5 both cut clean tags but CI failed downstream for different self-hosted reasons: - v1.2.4 failed on parallel apt-lock race (fixed) - v1.2.5 failed with "TOML parse error at line 5 column 9" because rust-cache v2's default cache-bin=true prunes $CARGO_HOME/bin of any binary not installed via `cargo install`. `rustup` itself is installed by rustup-init, not cargo install, so it got flagged as "unknown" and deleted on cache save. Next job hits the cargo symlink that points at a missing rustup, which resolves somehow to a very old cargo that can't parse our Cargo.toml. Fix: - Set `cache-bin: "false"` on every Swatinem/rust-cache@v2 call. We still cache target/ + registry (the big win), just not bin/. Binaries are stable across runs on our self-hosted box anyway. - Reinstalled rustup inside each per-runner CARGO_HOME on the server to recover from the broken state. Also in this release: - PR #83: new `mhrv-rs scan-sni` subcommand. Pulls Google's published IP ranges, does PTR lookups via dns.google on each IP, filters to Google-related hostnames, then TLS-probes each discovered SNI against the configured google_ip to see which ones bypass DPI. Useful for rebuilding a working SNI pool on a new ISP. Adds the `url` crate dep. Same user-facing code as v1.2.4/v1.2.5 (PRs #78, #79, README Android note) plus PR #83 and the CI fixes on top. |
||
|
v4g4b0nd_0x76
|
ca10f775dc |
scan-sni: add automated SNI discovery + DPI validation (#83)
New `mhrv-rs scan-sni` subcommand: pulls Google's published IP ranges, issues PTR lookups via dns.google, filters results to Google-related hostnames, then TLS-probes each discovered SNI against the user's configured `google_ip`. Prints the SNIs that pass DPI for the user to paste into `sni_hosts`. Also expands the hardcoded FAMOUS_GOOGLE_DOMAINS list the existing scan-ips command already used. Adds `url` crate for URL parsing in the DNS-over-HTTPS client. No other behavioural changes. |
||
|
therealaleph
|
af44abbcd3 |
v1.2.5: CI self-hosted apt-lock fix (v1.2.4 release was incomplete)
v1.2.4 tagged cleanly but its CI failed — parallel Linux matrix jobs
on the self-hosted runners all raced on `/var/lib/apt/lists/lock` and
failed the `sudo apt-get install` step within ~20s. v1.2.4's release
job therefore skipped and no assets were published.
Fix:
- Pre-installed every apt dependency the workflow needs on both
self-hosted runners (eframe system libs, gcc-aarch64-linux-gnu,
gcc-arm-linux-gnueabihf).
- Seeded per-runner cargo linker configs at
/home/ghrunner/cargo-{01,02}/config.toml so the "echo
[target.xxx] linker = ..." workflow step is also unnecessary.
- Gated the "Install Linux eframe system deps" and the two cross-
compile-toolchain steps on `runner.environment == 'github-hosted'`
so only hosted runners call apt-get; self-hosted runners skip the
whole thing and use pre-installed tooling.
Re-tagging as v1.2.5 since v1.2.4 is an abandoned tag (git tag exists
but no GitHub Release was cut for it).
Same code changes as what v1.2.4 was meant to ship: PR #78 range-
parallel validation, PR #79 port-collision rejection, README note
on Android 7+ user-CA trust.
|
||
|
therealaleph
|
cb07311cf1 |
v1.2.4: range-parallel validation + port-collision guard + README Android note
- PR #78: validate Content-Range on 206 responses in the range-parallel path before stitching. Prevents malformed partials from being combined into a fake 200 OK. Invalid probe falls back to a normal single GET; invalid later chunks fall back to the validated probe response instead of shipping truncated/wrong data. - PR #79: reject configs with listen_port == socks5_port at validation time (both config-load and UI form) instead of letting the second bind fail at runtime with a less clear error. - README: add an explicit note about the Android 7+ user-CA trust limitation so future reporters (#74, #81, and the next dozen) find the answer in the docs instead of in a support thread. The previous "every app routes through the proxy" line was misleading — TUN captures all IP traffic but HTTPS still needs app-level trust of our MITM CA, which most non-browser apps don't grant. Running through the new self-hosted CI pipeline. Warm rust-cache should bring the full matrix in under ~7 minutes. |
||
|
therealaleph
|
15e3e38745 |
v1.2.3: move CI to self-hosted runners + rust-cache
Linux / Android / mipsel build jobs now run on two self-hosted runners on a Hetzner 8-core / 31 GB Ubuntu 24.04 box with Rust, Android SDK+NDK r26c, all cross-compile toolchains and Docker pre-installed. macOS and Windows still run on GitHub-hosted — we don't self-host those OSes and the free minutes on a public repo are plenty. Adds Swatinem/rust-cache@v2 to every cargo-using job so target/ + cargo registry survive between runs. With warm caches the Linux jobs take ~1min each and the Android job ~3-4min; cold runs are ~9min for Android and ~2min for everything else. Release wall time before this change was ~13m consistently; it should now sit around 6-7m. No new user-facing code in this release — primarily an infra change exercised by an actual tag-push so we verify the full pipeline works end-to-end from the new runners. |
||
|
therealaleph
|
e48a8f6add |
v1.2.2: Android Start crash fix + google_ip preservation + chromewebstore SNI
Three user-facing fixes: - Android Start crash in google_only mode (#73): every early-return path in startEverything now satisfies Android 8+'s foreground-service contract by calling startForeground before stopSelf. Previously if you opened the app, selected google_only mode, and tapped Connect without filling deployment ID + auth key (which google_only doesn't need anyway), the service crashed with ForegroundServiceDidNotStartInTimeException. Also gated the deployment-ID requirement on mode == APPS_SCRIPT. - google_ip auto-overwrite on Start (#71): some carriers serve poisoned DNS for www.google.com that resolves but refuses TLS, clobbering working IPs users had manually set. DNS lookup now only fires when the field is blank — manual configs are preserved across Connect. Explicit "Auto-detect" button still refreshes on demand. - chromewebstore.google.com added to DEFAULT_GOOGLE_SNI_POOL and DEFAULT_SNI_POOL (#75). Same family as the rest of the pool — wildcard cert, GFE-hosted. |
||
|
therealaleph
|
1d5d13d63d |
v1.2.1: IP-literal fast-fail + more SNIs + x.com GraphQL fix + Android SNI paste
Rollup of the three upstream-Python ports plus an Android UX polish: - plain_tcp_passthrough: 4s connect timeout for IP literals (10s for hostnames). Halves Telegram DC-rotation latency when the current DC is DPI-dropped. - DEFAULT_GOOGLE_SNI_POOL / DEFAULT_SNI_POOL: +maps, chat, translate, play, lens.google.com. More fingerprint spread, and maps/play pass DPI on some carriers where shorter *.google.com names don't. - handle_mitm_request: x.com GraphQL URL truncation — strip everything after the first & when the path matches /i/api/graphql/.../?variables=. x.com's variables+features+fieldToggles blob overflows Apps Script's URL cap; `variables=` alone renders the timeline. - Android SNI editor: paste-and-add now accepts a full list separated by whitespace / commas / newlines, dedupes, and merges with existing selection. Closes the "add them all at once" ask from #47. - rlimit.rs: fence the example error log in a `text` code block so rustdoc stops trying to compile it. |
||
|
dazzling-no-more
|
b90b003cbc |
feat: add google_only bootstrap mode (#62)
Second operating mode for users whose network already blocks script.google.com and therefore cannot reach it to deploy Code.gs in the first place. In google_only, the client runs only the SNI-rewrite tunnel to *.google.com and the other Google-edge suffixes that are already allowlisted; non-Google traffic falls through to direct TCP. No script_id or auth_key is required. Once Code.gs is deployed, the user switches to apps_script mode and pastes the Deployment ID. - config: Mode enum, relaxed validation when mode is google_only - proxy_server: mode check in dispatch_tunnel; DomainFronter is now Option<Arc<_>> so it is not constructed in google_only - desktop UI and Android app: Mode dropdown, Apps Script fields disable in google_only - README: bootstrap subsection in English and Persian - config.google-only.example.json - version bump to 1.2.0 + changelog entry Backward compatible with existing apps_script configs. |
||
|
Shin (Former Aleph)
|
5a108f73cb |
v1.1.5: merge upstream safety fixes + Telegram default = file + link only (#60)
Contains the three safety fixes from PRs #48/#49/#50 and the Persian README RTL polishing from #58, all squashed into main. Merge details already in their individual PR comments; summary: #48: reject truncated Content-Length relay responses (previously silently accepted whatever bytes arrived before EOF) #49: reject truncated or malformed (missing CRLF) chunked-encoding relay responses (same class of silent-acceptance bug) #50: restrict the SNI-rewrite tunnel dispatch to port 443. Plain HTTP (:80) targets that happened to match google.com / hosts override were being steered into the TLS tunnel and blocking waiting for a ClientHello that would never arrive. #58: trailing-whitespace line-breaks on Persian bullet lists in README so the RTL rendering doesn't collapse consecutive items into a single paragraph. Test suite grew from 54 to 58 passing (three new negative tests for the relay-reader correctness fixes + one SNI-rewrite port filter). Telegram CI notify default switched to file-plus-link: - script gains a `--with-changelog` flag; default OFF - workflow only passes it when `vars.TELEGRAM_INCLUDE_CHANGELOG=true` - every routine release now posts just the APK + short caption (title + SHA-256 + repo URL + release URL) with no long body To include bullets for a given release again: gh variable set TELEGRAM_INCLUDE_CHANGELOG --body true The existing `vars.TELEGRAM_NOTIFY_ENABLED` job-level gate remains — changelog toggle is orthogonal to enable/disable. Also closes PR #55 without merging; ads/analytics domains were being lumped under a YouTube-specific toggle, and the PR committed per- machine \`.cargo/config.toml\` + zig-cc cross-compile helpers that would have broken CI on actual Windows / macOS runners. |
||
|
Shin (Former Aleph)
|
8d2f90b0a7 |
v1.1.4: YouTube video streaming — expanded SNI-rewrite list + parallel Range fetcher (#56)
Users of the upstream Python port
(github.com/masterking32/MasterHttpRelayVPN) reported that YouTube
videos render fine through theirs while the Rust port stalls. Diff
against the Python source exposed two substantive gaps we were
missing:
1. SNI-rewrite list was much shorter than upstream. Added:
gvt1.com, gvt2.com — Google Video Transport CDN (YouTube
video chunks + Chrome auto-updates +
Play Store downloads)
doubleclick.net — ads
googlesyndication.com
googleadservices.com
google-analytics.com
googletagmanager.com
googletagservices.com
fonts.googleapis.com — already covered by the googleapis.com
suffix but mirrored explicitly for clarity
These are all on Google's GFE IP pool, so they route over the
existing SNI-rewrite tunnel (direct to `google_ip` with SNI
rewritten) instead of the quota-limited Apps Script relay.
2. No range-parallel download path. Apps Script's per-call latency
is ~flat (~1-2s regardless of payload), so a 10 MB single GET
takes ~10s round-trip; the player times out or stutters. Upstream
Python's `relay_parallel` probes with Range: bytes=0-262143, and
if the origin supports ranges, fetches the rest in parallel
256 KB chunks (up to 16 concurrent). Ported that logic as a new
`DomainFronter::relay_parallel_range` method, called from both
MITM-HTTPS and plain-HTTP handlers for GETs without a body. Rust
implementation uses `futures::stream::buffered` for ordered
bounded-concurrency fan-out; cache layer already skips Range
requests (added defensive check in relay() too).
The existing single-script fan-out (`parallel_relay` config) is
complementary — it races N script IDs for each individual chunk,
where the range-parallel path slices the overall download. Both are
active simultaneously when both are configured.
Helper functions for HTTP parsing (split_response,
parse_content_range_total, rewrite_206_to_200, assemble_full_200)
mirror the Python equivalents.
No behaviour change for non-GET requests; no cache-correctness
changes for GETs that don't return 206.
|
||
|
Shin (Former Aleph)
|
5a5139f6ea |
v1.1.3: portable-atomic polyfill so mipsel-softfloat compiles (#46)
v1.1.2 reached cargo build inside the mipsel docker this time (YAML-fold bug finally out of the way) and surfaced the real underlying problem: MIPS32 has no native 64-bit atomic instructions, so std::sync::atomic::AtomicU64 doesn't exist on mipsel-unknown-linux-musl. Three call sites (DomainFronter stats counters + the request-cache) failed to resolve the import. Fix: depend on `portable-atomic` with the `fallback` feature and import AtomicU64 from there instead of std. The API is identical (same associated methods, same Ordering accepted), so the two touched files change only the `use` line. On 64-bit targets portable-atomic compiles down to the native 64-bit atomic insns with no overhead; on MIPS32 it uses a global spinlock, which is fine for counter increments that happen a few times per relay. Cache.rs and domain_fronter.rs both updated. No other callers of AtomicU64 in non-cfg-gated code (android_jni.rs has it but is gated `#![cfg(target_os = "android")]`, so mipsel-linux-musl never sees it). `cargo test --lib` / `cargo build` still pass on host. |
||
|
Shin (Former Aleph)
|
383bea008e |
v1.1.2: actually-green mipsel-softfloat (YAML comment-fold bug) (#44)
v1.1.1 still failed the mipsel CI matrix for a non-obvious reason.
The `Build CLI (mipsel-softfloat via docker)` step passed a
multi-line argument to `sh -c "..."` with `\` line continuations
and inline `#` comments:
sh -c "set -eux; \
# The image ships with a pre-installed nightly ... \
rustup toolchain uninstall ... \
..."
YAML's `run: |` block-scalar folds that into a single line on the
shell side — backslash-newline collapses become spaces. The
payload handed to `sh -c` becomes one long line in which the
first `#` comments out everything that follows on that line, so
the only command that actually ran inside the container was
`set -eux;`. Everything after it was a comment. The container
exited successfully (set -eux + empty; is a zero-exit no-op),
the `target/` directory never got created, and the post-docker
`sudo chown -R "$(id -u):$(id -g)" target` failed with
chown: cannot access 'target': No such file or directory
Process completed with exit code 1.
which fooled me into thinking the toolchain logic failed, when
actually NO toolchain logic ran at all.
Fix: use bash with a single-quoted multi-line script. Single
quotes preserve newlines literally, so `#` stays a
line-terminating comment rather than collapsing. Heredoc-style
formatting; same commands as before.
No other changes. Version bumps only (Cargo + Android versionCode/
versionName). Telegram notify stays off via the repo-variable
gate we added yesterday.
|
||
|
Shin (Former Aleph)
|
a7b63ee53a |
v1.1.1: accounts.googl.com in SNI pool + mipsel-softfloat lands green (#43)
SNI rotation pool gains `accounts.googl.com` (issue #42). Reporter confirmed it passes DPI on Samantel and MCI — Iranian carriers that selectively block some of the longer google.com subdomain SNIs. `googl.com` is a Google-owned redirect alias served off the same GFE pool, so the TLS handshake works against `google_ip:443` without extra plumbing; we just present the name in the ClientHello for fingerprint diversity. Mirrored into the Android default pool too. The mipsel-softfloat target finally builds green in CI — two earlier bugs that compounded: messense doesn't publish a `:mipsel-musl-softfloat` image tag (fixed in main earlier by using `mipsel-musl` + `RUSTFLAGS=-C target-feature=+soft-float` + `-Z build-std`), and the pre-installed nightly in that image has a broken component state that rustup can't upgrade in place (fixed by uninstalling nightly first). Both fixes are in the tagged commit this time. Closes issue #26. Previous issues addressed in v1.1.0 that this release documents the closing of: - issue #28: "egui_glow requires opengl 2.0+" on old Windows / RDP / VMs — fixed via dual glow+wgpu compile + MHRV_RENDERER env var + run.bat auto-retry. - issue #37: connection-mode picker (VPN/TUN vs Proxy-only) so users who already run another VPN can still use mhrv-rs as a per-app HTTP/SOCKS5 proxy. Version bump: 1.1.0 → 1.1.1 (versionCode 110 → 111). |
||
|
Shin (Former Aleph)
|
28be8f67d5 |
v1.1.0: unified Connect button, proxy mode, app splitting, Persian UI, MIPS build (#41)
Major feature release across Android + desktop. Six items the user asked for, verified end-to-end on the emulator. Android ------- * Unified Connect/Disconnect button. Single large button swaps between green "Connect" (when the service is down) and red "Disconnect" (when it's up). Tracks the real service state via a new process-wide `VpnState` singleton flipped from the service's startEverything() / teardown() — not optimistic, the button only reports what the service actually did. * Connection mode dropdown (issue #37). Two options: VPN (TUN) — routes every app — and Proxy only — user configures per-app via Wi-Fi proxy to 127.0.0.1:8080 (HTTP) / :1081 (SOCKS5). PROXY_ONLY skips VpnService.prepare() entirely (no OS VPN grant prompt) and the service just keeps the foreground listeners up. Default is VPN_TUN so existing behaviour is preserved for users who upgrade without looking at the dropdown. * App splitting. In VPN_TUN mode you can pick All / Only selected / All except selected, with a picker dialog that lists installed user-visible apps (LazyColumn with search, "show system apps" toggle, multi-select checkboxes). ONLY calls `Builder.addAllowedApplication()` for each chosen package; EXCEPT calls `addDisallowedApplication()` additive to the mandatory self-exclude. Requires QUERY_ALL_PACKAGES — added to the manifest along with a `<queries>` launcher-intent filter so the picker rows can render app labels, not just package strings. * Persian/English UI toggle with RTL. Top-bar TextButton cycles AUTO → FA → EN → AUTO. Persian strings live in `res/values-fa/strings.xml`; English in `res/values/strings.xml`. `AppCompatDelegate.setApplicationLocales()` is used as the persistence layer (plus `AppLocalesMetadataHolderService` meta and `locales_config.xml` for the per-app-language OS entry on API 33+). MainActivity overrides `attachBaseContext` to wrap the context with the right locale at the earliest possible moment — otherwise a saved preference wouldn't apply until the SECOND process after toggling. RTL swaps automatically because Persian is script="Arab" in Android's locale database. * Collapsible How-to-use card. The big instruction block that used to dominate the bottom of the screen now lives inside a CollapsibleSection that starts expanded for a fresh install (empty deployment URLs / auth_key) and collapsed otherwise. * Update check auto-fires on first composition, silent-on-up-to-date, snackbar-only-if-available. Still surfaces via the version badge tap for manual checks. * MhrvVpnService teardown guard was kept from v1.0.2 — `AtomicBoolean` makes the second caller a no-op, which is the SIGSEGV fix for "tap Stop, app closes" from before. Stress-tested under rapid Connect/Disconnect cycles. Desktop ------- * Fix: Advanced section silently resetting on every Save. `ConfigWire` was missing `fetch_ips_from_api` / `max_ips_to_scan` / `scan_batch_size` / `google_ip_validation` — every persist dropped them, every reload fell back to the serde defaults, user saw their Advanced toggles reset. Added the fields to the wire struct (issue surfaced by the user as "Advanced resets after reopening the app"). * Windows renderer fallback (issue #28). `eframe` is now built with BOTH `glow` (OpenGL 2+) and `wgpu` (DX12/Vulkan/Metal); runtime defaults to glow for compat but honours `MHRV_RENDERER=wgpu` for boxes that crash with "egui_glow requires opengl 2.0+" — old Windows hardware, RDP sessions, VMs without GPU acceleration. `run.bat` auto-retries the UI with `MHRV_RENDERER=wgpu` if the first launch exits non-zero, so users don't need to know about the flag. CI -- * Added OpenWRT mipsel-softfloat build target (issue #26). MT7621 routers specifically need soft-float because the CPU has no FPU; a hard-float binary segfaults on first fp op. Built via `messense/rust-musl-cross:mipsel-musl-softfloat` docker image + nightly Rust with `-Z build-std` (mipsel is Rust tier 3 since 1.72, no pre-built std). Marked `continue-on-error: true` — the tier-3 target occasionally regresses and we'd rather ship the rest of the release than block on MT7621 support. Signature / versioning ---------------------- * versionCode 110, versionName 1.1.0; Cargo bumped to 1.1.0. * Release APK signed with the committed `release.jks` (same as v1.0.2), so v1.0.2 → v1.1.0 upgrades install in-place without the uninstall-first dance. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Shin (Former Aleph)
|
64409f6b41 |
v1.0.2: stable release signature, idempotent Stop, top-level Settings for CA install (#33)
Three fixes + one behaviour change from v1.0.1 reports. APK signature is now stable (release.jks committed) ---------------------------------------------------- v1.0.0 and v1.0.1 signed release APKs with Gradle's auto-generated debug keystore, which is randomly generated per machine and per CI runner. Result: every upgrade failed with INSTALL_FAILED_UPDATE_INCOMPATIBLE and users had to uninstall first. Unfixable without a stable key. android/app/release.jks now holds that key, committed to the repo with the password in plaintext in build.gradle.kts. This is fine for a FOSS sideload project without a Play Store identity — the trust model is "trust the source tree you pulled from," not "trust the key we hold." Anyone forking and shipping a rebranded build should generate their own key. One-time cost: v1.0.1 → v1.0.2 STILL requires uninstall, because we're switching signature keys. Every upgrade from v1.0.2 onward is clean. Stop no longer (sometimes) closes the app ----------------------------------------- teardown() is reachable from three paths on two threads: 1. ACTION_STOP onStartCommand branch (mhrv-teardown worker) 2. onDestroy after stopSelf (main thread) 3. VpnService revocation out-of-band (main thread) Running the full native cleanup sequence twice races the two threads through Tun2proxy.stop() → fd.close() → Native.stopProxy(handle) on state that's already been nullified — SIGSEGV source, user-visible as "tap Stop, app disappears." New AtomicBoolean `tornDown` gates entry: first caller wins, every subsequent caller logs "teardown: already done" and returns. onDestroy also wraps the call in try/catch — crashing out of onDestroy takes the whole process with it, which is exactly the bug we're trying to fix. Smoke-tested on emulator: teardown now logs teardown: begin caller=mhrv-teardown ... clean sequence ... teardown: done onDestroy entered teardown: already done, skipping (caller=main) onDestroy done with PID unchanged throughout. CA install now routes to the Settings search -------------------------------------------- Old flow: `Settings.ACTION_SECURITY_SETTINGS` deep-link, then walk "Encryption & credentials → Install a certificate → CA certificate". That path varies wildly between OEMs (Samsung buries it under "Biometrics and security → Other security settings"; Xiaomi under "Passwords & Security → Privacy"; Pixel splits it between "More security settings" and "Privacy controls" depending on Android version). Users got lost. New flow: open the top-level Settings app (`Settings.ACTION_SETTINGS`) and instruct the user to use the Settings search bar to find "CA certificate". Search is consistent across OEMs and Android versions; the menu paths are not. Dialog, snackbar, and `docs/android.md` copy all updated to match. Version bump: 1.0.1 → 1.0.2 (versionCode 101 → 102). releases/mhrv-rs-android-universal-v1.0.1.apk replaced with the v1.0.2 build. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Shin (Former Aleph)
|
b734f41faa |
v1.0.1: auto-resolve google_ip, robust Stop, Check-for-updates, front_domain repair (#31)
Three reported issues from v1.0.0 — one real bug, two UX gaps. google_ip auto-resolve (THE FIX) -------------------------------- Google rotates the A record for www.google.com across their anycast pool. A hardcoded default IP breaks new installs on any network that isn't geo-homed to the same edge — symptom is "all SNIs time out" even with a fresh deployment. On Start and via a new "Auto-detect" button, we now do a JVM-side InetAddress lookup BEFORE establishing the VPN (so the resolver uses the underlying network, not our own Virtual-DNS TUN — avoids a loop), update the config, and continue. The auto-resolve lives in the HomeScreen click handler (not MainActivity) so it goes through the same `persist(cfg)` the text fields use. Previous iteration did `ConfigStore.load → modify → save` directly to disk, which left Compose's in-memory cfg stale and a subsequent field edit would overwrite the fresh IP. One source of truth now. Also defensively repairs front_domain: if it's been corrupted into an IP literal (bad paste, whatever) we restore "www.google.com" — the TLS SNI on the outbound leg has to be a hostname or the handshake lands on the wrong vhost. Robust Stop ----------- The Stop button now dispatches both ACTION_STOP (graceful: runs teardown, stops tun2proxy, closes TUN fd, shuts down Rust runtime) AND stopService() (defensive: covers force-closed-then-reopened zombie state where Android auto-restarted our START_STICKY service in a fresh process and the in-memory TUN reference is gone). Check-for-updates ----------------- Tapping the version badge in the top bar now runs the same update_check that the desktop UI uses, via a new `Native.checkUpdate()` JNI entry point. Returns a JSON blob the Kotlin side parses into an "Up to date", "Update available: v→v <url>", "Offline: ...", or "Check failed: ..." snackbar. Mirrors the desktop's behavior so a user doesn't have to manually poll GitHub for new builds. Crash visibility ---------------- New MhrvApp.kt registers a process-wide uncaught exception handler. Crashes are now stamped into logcat under the `mhrv-crash` tag with the thread name before the default handler kills the process — previously the JVM crash in coroutines / the log drain / the tun2proxy worker was invisible unless you caught the dropoff in real time. Version bump: 1.0.0 → 1.0.1 (versionCode 100 → 101). Release APK rebuilt and replaces the 1.0.0 copy in releases/; CI will regenerate on the v1.0.1 tag push. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Shin (Former Aleph)
|
91015b0594 |
v1.0.0: multi-arch Android APK + GitHub Actions release job + install docs (#30)
Version bump reflects the scope — a unified Rust core that now ships
for desktop (Linux/macOS/Windows) AND Android from the same crate.
Android changes:
- build.gradle.kts: ABI filters expanded to arm64-v8a + armeabi-v7a
+ x86_64 + x86. cargoBuild{Debug,Release} pass all four ABIs to
cargo-ndk in a single invocation. normalizeTun2proxySo() walks every
ABI dir now (was arm64-only).
- Release buildType signs with the debug keystore — no Play Store
target, so signature identity doesn't matter, installability does.
Gradle auto-provisions ~/.android/debug.keystore if absent, so CI
runners inherit this without extra setup.
- versionName 1.0.0, versionCode 100 (room to bump monotonically).
CI:
- release.yml gets a dedicated `android:` job that sets up JDK 17,
Android SDK/NDK 26, all four rust-android targets, installs
cargo-ndk, runs assembleRelease, and uploads a single universal APK
named `mhrv-rs-android-universal-v<version>.apk` into the same
`dist/` collected by the release job downstream.
- `release:` job now gates on `needs: [build, android]` so tagging
v1.0.0 triggers both build matrices before cutting the GitHub
release.
Docs:
- docs/android.md — full 10-step install walk-through: APK sideload,
Apps Script deployment (with "Advanced → Go to (unsafe) → Allow"
reality check), config paste, SNI reachability test, MITM CA
install with OEM-specific nav paths (Pixel / Samsung / Xiaomi),
Start, troubleshooting common failure modes. Also documents the
known limitations — Cloudflare Turnstile loops (inherent to the
Apps Script egress IP pool), UDP/QUIC not tunnelled, IPv6 leaks,
Apps Script daily quota — so users know what to expect before
trying it on a site that won't work.
- releases/README.md — APK row added to the English and Persian
tables, version bumped everywhere to v1.0.0.
- Top-level README — Android listed under Platforms with a link
to docs/android.md.
Release artifact:
- releases/mhrv-rs-android-universal-v1.0.0.apk — 38 MB universal
APK built locally from this tree. Installs + launches on API 24+.
The CI job will regenerate it on tag push; this is the copy
committed for users who can't reach GitHub Releases.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Shin (Former Aleph)
|
96d1352728 |
Add Android app with full TUN bridge + two proxy fixes the desktop also wants (#29)
The app is a Kotlin/Compose front-end that reuses the mhrv-rs crate
via JNI. It speaks VpnService to get a TUN fd, hands that to tun2proxy,
and funnels every app's traffic through the in-process SOCKS5 listener —
no per-app proxy setup on the device.
Two fixes in `src/proxy_server.rs` apply to desktop builds too:
* SNI peek via `LazyConfigAcceptor`. When a browser uses DoH (Chrome's
default), tun2proxy hands us a raw IP in the SOCKS5 CONNECT. Minting
a MITM cert for the IP produced `ERR_CERT_COMMON_NAME_INVALID` on
Cloudflare-fronted sites. We now read the ClientHello's SNI first
and use that both as the cert subject and as the upstream host for
the Apps Script relay (fetching `https://<IP>/...` with an IP in the
Host header gets rejected by CF anyway).
* Short-circuit CORS preflight at the MITM boundary. `UrlFetchApp.fetch()`
rejects `OPTIONS` with a Swedish "Ett attribut med ogiltigt värde
har angetts: method" error, which silently broke every fetch()/XHR
preflight and was the root cause of "JS doesn't load" on Discord,
Yahoo, and similar. Since we already terminate the TLS the browser
talks to, answering the preflight with a permissive 204 is safe —
the real request still goes through the relay.
Android-side capabilities (feature-parity with `mhrv-rs-ui` where it
fits on a phone):
* multi-deployment ID editor
* SNI rotation pool + per-SNI "Test" + "Test all" (JNI into scan_sni)
* live logs panel (JNI ring buffer drained on a 500 ms poll)
* Advanced section: verify_ssl, parallel_relay, log_level, upstream_socks5
* CA install flow that matches modern Android's reality: saves
`Downloads/mhrv-ca.crt` via MediaStore, deep-links Security settings,
then verifies post-hoc by fingerprint lookup in AndroidCAStore (the
KeyChain intent dead-ends with a Close-only dialog on Android 11+)
* Start/Stop debounced to dodge an emulator EGL renderer crash on
rapid taps
Theme matches the desktop palette exactly — always-dark, accent
`#4678B4`, card fill `#1C1E22`, 4dp button / 6dp card radii.
No dynamic color, no light scheme: the desktop is always dark and
we follow.
Build wiring:
* `Cargo.toml`: `cdylib` crate-type added; `jni` + `tun2proxy`
scoped to `cfg(target_os = "android")` so desktop builds pay
nothing.
* `src/data_dir.rs`: `set_data_dir()` override so the Android app's
private filesDir replaces the `directories` crate's desktop default.
* `src/android_jni.rs`: JNI entry points for start/stop/exportCa plus
a ring buffer draining to `Native.drainLogs()` and `testSni()` that
wraps `scan_sni::probe_one`.
* Gradle task chain runs `cargo ndk` before each assemble; post-step
normalizes tun2proxy's hash-suffixed cdylib to a stable filename
so `System.loadLibrary("tun2proxy")` works.
Verified end-to-end on an API 34 emulator: ipleak, yahoo, discord,
cloudflare.com all render; TLS is MITM-ed under our user-installed
CA; service survives rapid Stop/Start cycles.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
therealaleph
|
a9ad697b6a |
v0.9.4: actionable diagnostic when outbound TLS to Google edge fails (#18 follow-up)
@Behzad9 reports: after the EMFILE fix in v0.9.3 landed cleanly, the
relay now fails with a different error:
ERROR Relay failed: io: invalid peer certificate: UnknownIssuer
repeated on every request. This is rustls (via domain_fronter) rejecting
the server cert that whatever sits on our TLS connection to google_ip
presents. In practice this means one of three things, in decreasing
order of likelihood for an Iranian OpenWRT user:
1. The ISP / a middlebox is intercepting outbound TLS to Google IPs
and presenting its own cert. webpki-roots (Mozilla trust store,
baked in) correctly rejects it.
2. The user's google_ip setting points at a non-Google host.
3. Router clock is wildly off (NTP not synced), certs look not-yet-valid.
Before this change: one identical ERROR per failed relay, no guidance.
Log filled with the same line.
Now:
- New DomainFronter::log_relay_failure() detects cert-related error
strings (UnknownIssuer, CertificateExpired, CertNotValidYet,
NotValidForName, 'invalid peer certificate').
- First occurrence logs an ERROR with the three root causes and three
concrete fixes: run to find a working Google IP,
check the system clock, or as a LAST RESORT set verify_ssl=false
(with the explicit warning that traffic is then only protected by
the Apps Script auth_key, not outer TLS).
- Subsequent occurrences drop to debug so the log stays readable —
an AtomicBool gate on the DomainFronter instance tracks whether
the hint was shown. Resets on proxy restart.
- Non-cert errors still log at error level unchanged.
49 tests pass, no code-path regressions (log line content changed, not
behavior). Shipping so users hit this get actionable output.
|
||
|
therealaleph
|
93fac57f5f |
v0.9.3: accept-loop backoff on EMFILE + louder rlimit diagnostics (issue #18)
@Behzad9 on #18: the OpenWRT 'No file descriptors available' errors are back in v0.8.0+, this time logged as a wall of thousands of identical ERRORs within seconds of activating the proxy. Two real bugs, now fixed: === 1. accept() loop had no backoff === Previous code: loop { match listener.accept().await { Ok(x) => ..., Err(e) => { tracing::error!(...); continue; } // tight loop } } On EMFILE (RLIMIT_NOFILE exhausted), accept() returns synchronously, the match re-runs instantly, accept() EMFILEs again, forever. The tight loop ALSO starves the tokio runtime of CPU that existing connections need to finish and close their fds — so the problem never clears on its own. It's a self-sustaining meltdown. New accept_backoff() helper (in proxy_server.rs) wraps both the HTTP and SOCKS5 accept loops: - Detects EMFILE/ENFILE via raw_os_error (24 or 23). - Sleeps proportional to how long the pressure has lasted (50 ms first hit, ramping to a 2 s cap around hit #40). Gives existing connections a chance to finish and free fds. - Rate-limits the log line: one WARN on the first EMFILE with fix instructions, then one every 100 retries. No more walls of identical errors. - Resets the counter on the next successful accept. - Non-EMFILE errors (ECONNABORTED from clients that went away during handshake, etc.) get a plain single-line error + 5 ms sleep so we still don't tight-loop on any unexpected error. End-to-end verified: ran mhrv-rs under , flooded the SOCKS5 port with 247 concurrent connections to trip EMFILE. Before: log would have been 1000s of identical lines. After: exactly 1 warning, listener stayed quiet, fds drained, accept resumed. === 2. RLIMIT_NOFILE bump was too conservative + silent === Previous behavior: target 16384 soft, cap to existing hard limit, no log. On constrained systems where hard is already tiny, we'd stay at the tiny limit silently. rlimit.rs now: - Targets 65536 soft. - ALSO tries to raise the hard limit up to /proc/sys/fs/nr_open on Linux (Linux allows a non-privileged process to bump its own hard limit up to the kernel ceiling, usually 1048576 on modern kernels). On macOS/BSD we skip this — only bump soft. - Logs WARN on startup if soft ends up <4096 with the exact fix ('ulimit -n 65536' or use the procd init). No more silent failure. - Logs INFO with the before/after limits otherwise, so field bug reports tell us immediately whether the kernel cap is the real bottleneck. Moved the rlimit call from main() pre-logging to post-init_logging so its tracing output actually lands in the log panel + stderr. Small reorganization only. 49 tests pass, musl x86_64 cross-compile verified locally. |
||
|
therealaleph
|
9768cd9edb |
v0.9.2: update check tunnels through proxy + one-click asset download (#15 follow-up)
@zula-editor reported on issue #15 that the Check-for-updates button was returning HTTP 403 on their ISP — classic GitHub unauthenticated-API rate limit (60/hour per IP) on a shared NAT IP. They also asked for the update to actually be downloadable from the app, not just a page link. Both addressed: === Route update check through our own proxy when running === New mhrv_rs::update_check::Route enum: - Direct: straight rustls to api.github.com (existing behavior) - Proxy { host, port }: HTTP CONNECT through our local HTTP proxy listener → MITM → Apps Script → api.github.com. When the proxy is running, the UI automatically picks Proxy. From GitHub's POV the request now comes from Apps Script's IP range (a Google datacenter) — completely different rate-limit bucket from the user's ISP IP, AND works even if GitHub is blocked on their network. Routing over proxy means the MITM leaf for api.github.com has to be trusted in the update_check's TLS config. build_root_store() now conditionally adds our own CA cert from data_dir::ca_cert_path() to the webpki roots when Route::Proxy is in use. Direct path is unchanged. === Download button === The UpdateCheck::UpdateAvailable variant now carries an optional ReleaseAsset { name, download_url, size_bytes } picked by pick_asset_for_platform() from the GitHub API's assets[] array. Preference list per (OS, arch): - macOS arm64 → mhrv-rs-macos-arm64-app.zip, else tar.gz - macOS amd64 → mhrv-rs-macos-amd64-app.zip, else tar.gz - Windows → mhrv-rs-windows-amd64.zip - Linux aarch64 → mhrv-rs-linux-arm64.tar.gz - Linux armv7 → mhrv-rs-raspbian-armhf.tar.gz - Linux x86_64 → mhrv-rs-linux-amd64.tar.gz UI: when an update is available AND we have an asset, the transient status line grows an accent-blue 'Download X.Y MB' button. Clicking fires Cmd::DownloadUpdate, which pipes the asset through the same Route (proxy if running, direct otherwise), writes it to UserDirs::download_dir() (~/Downloads on most systems), and shows a 'show in folder' button that opens Finder / Explorer / xdg-open on the containing directory. Three new unit tests for asset-picking. The gated live test now takes a Route argument (Direct) so it keeps working across the API shape change. 49 tests pass. Also refreshed in-repo releases/ archives to v0.9.1 alongside. |
||
|
therealaleph
|
0beec6a277 |
v0.9.1: normalize X/Twitter GraphQL URLs for cache hit rate (issue #16)
User @barzamini pointed out an optimization from the Python community (originally from seramo_ir): X/Twitter GraphQL URLs look like https://x.com/i/api/graphql/{hash}/{op}?variables=...&features=...&fieldToggles=... The features and fieldToggles params change across sessions and even within a session, busting our 50 MB response cache on every request to the same logical query. Stripping everything after 'variables=' lets identical logical queries collapse into one cache entry, dramatically reducing quota usage when browsing Twitter through the relay. Implementation: - src/domain_fronter.rs: new normalize_x_graphql_url() helper. Matches exactly the Python patch's pattern (host == 'x.com', path starts with /i/api/graphql/, query starts with variables=). Truncates at the first '&' past the '?'. Applied at the top of relay() so the normalized URL feeds BOTH the cache key AND the request sent to Apps Script — so we save on Apps Script quota too, not just on return-trip bytes. - src/config.rs: new opt-in normalize_x_graphql bool (default false). Off by default because strict X endpoints may reject trimmed requests; user should flip it on and watch for regressions. - src/bin/ui.rs: checkbox in the Advanced section, 'Normalize X/Twitter GraphQL URLs', with tooltip explaining the trade-off and crediting the source. - Four new unit tests in domain_fronter::tests covering: the happy path trim, non-x.com hosts pass through unchanged, non-graphql x.com paths pass through unchanged, and idempotency. 48 tests total, all green. Credit: idea by seramo_ir, Python patch at https://gist.github.com/seramo/0ae9e5d30ac23a73d5eb3bd2710fcd67, implementation request by @barzamini in issue #16. |
||
|
therealaleph
|
3387d94ed9 |
v0.9.0: UI redesign + stricter end-to-end test verification
=== UI redesign (zero new deps, same binary size) ===
Entire App::update() rewritten around three ideas:
1. Section cards. Form rows are grouped inside rounded frames with
faint fills and small-caps headings:
- 'Apps Script relay' — Deployment IDs (textarea) + Auth key
- 'Network' — Google IP (+inline scan button), Front
domain, Listen host, HTTP+SOCKS5 ports
on one row, SNI pool button
- Collapsing 'Advanced' — upstream SOCKS5, parallel dispatch,
log level, verify SSL, show auth key.
Closed by default — most users never
touch these.
2. Clearer action hierarchy. Primary buttons are accent-filled and
larger:
- Start (green filled, ▶ glyph, 120x32)
- Stop (red filled, ■ glyph, 120x32)
- Save config (blue accent filled, path shown inline after →)
- SNI pool (blue accent filled, inside Network section)
- Test relay (neutral, tall)
Secondary actions (Install CA / Check CA / Check for updates)
moved to their own compact row below, no longer competing.
3. Status + log clarity.
- Header version links to GitHub: → repo, →
the release tag page.
- Running/stopped status is now a pill-shaped colored chip at the
right end of the header (green fill + green dot when running,
red when stopped).
- Traffic stats in a 2-column layout inside the Traffic card —
7 metrics fit in 4 rows instead of a 7-row vertical strip.
- One compact transient status line above the log that auto-hides
after 10 seconds — replaces the previous stack of permanent
ca_trusted / test_msg / update_check labels that were pushing
the log panel off-screen.
- Log panel now has its own bordered frame (darker fill), a
'[x] show' checkbox that hides it entirely when off, a 'save…'
button that writes the current log buffer to a timestamped
log-YYYYMMDD-HHMMSS.txt in the user-data dir, and a 'clear'
button. Empty state shows a muted placeholder instead of
silent void.
All helper functions (section, primary_button, form_row) live at the
top of ui.rs as small local helpers — no new modules, no new
dependencies.
=== Stricter end-to-end test (test_cmd.rs) ===
Previous test passed on any HTTP 200 status regardless of body.
After a user pointed out that the test reported PASS even after
they deleted their Apps Script deployment, updated the pass criteria:
1. Status must contain '200 OK'.
2. Body must parse as JSON.
3. JSON must have an 'ip' field with a valid IPv4 or IPv6.
Anything else → SUSPECT (returns false), with a specific log message
like 'HTML returned instead of JSON. The Apps Script deployment may
be deleted, not published to Anyone, or requires sign-in.'
Also now emits tracing::info!/warn!/error! alongside println!, so
the verdict + detail show up in the UI's Recent log panel instead
of disappearing to a stdout nobody sees.
One new unit test: looks_like_ip() accepts v4+v6, rejects empty,
rejects malformed, rejects overflowed octets. 44 tests total, all
green.
Verified locally end-to-end — UI launches clean, form loads config
cleanly, Start/Stop/Save all fire correctly, Test relay produces
the new PASS/SUSPECT verdict with the tracing detail visible in
the log panel, Check-for-updates hits GitHub and resolves with the
compact auto-hiding status line.
|
||
|
therealaleph
|
3534747e68 |
v0.8.6: armhf glibc pin + Check-for-updates button (#15)
=== PR #14 follow-up: armhf build runs on Pi Bookworm/Bullseye === PR #14 (merged earlier) added arm-unknown-linux-gnueabihf to the release matrix but pinned os=ubuntu-latest, which is 24.04 with GLIBC 2.39. Target armhf sysroot on 24.04 is Debian Trixie (GLIBC 2.39), far too new for a Raspberry Pi 2/3 on Bookworm (2.36) or Bullseye (2.31) — users would get 'GLIBC_2.39 not found' the same way the Linux-amd64 issue #2 folks did before we pinned them to 22.04. Fix: pin the armhf matrix entry to ubuntu-22.04, matching our other linux-gnu targets. Binary will link against GLIBC 2.35 max, which loads on Pi Bookworm and Bullseye. Also trimmed two trailing spaces. Locally verified the cross-compile: rust:latest + gcc-arm-linux- gnueabihf + proper CARGO_HOME config.toml produces a valid ARM 32-bit ELF (2.9 MB, armhf EABI5). === Issue #15: 'Check for updates' button in the UI === New src/update_check.rs module. On the user's click (no polling): 1. Tcp-probes github.com:443 with a 5s budget. If unreachable, we return Offline(reason) instead of a confusing 'update check failed' — distinguishes 'you're offline' from 'GitHub API misbehaved'. 2. HTTPS GET api.github.com/repos/.../releases/latest via the tokio + rustls stack (same hand-rolled HTTP pattern as domain_fronter — no new crate deps). Parses tag_name, strips the v-prefix, loose-semver-compares to env!(CARGO_PKG_VERSION). 3. Returns one of four UpdateCheck variants: Offline / Error / UpToDate / UpdateAvailable { release_url }. New UI wiring (src/bin/ui.rs): - Cmd::CheckUpdate enqueue variant - UiState::last_update_check { InFlight, Done(result) } - 'Check for updates' button next to the CA buttons - Result displayed as a colored small-text line under the CA info: green 'up to date', amber 'update available v0.8.5 → v0.8.6' with a clickable release-page hyperlink, red for offline/error. Verified end-to-end with a live github.com fetch (got a rate-limit HTTP 403 from my IP because I've been hitting the API a lot, but that's the expected Error() state — response classification was correct). Three unit tests for is_newer() and a gated live test for the full round-trip. 43 tests pass. |
||
|
therealaleph
|
014c2a8cd1 |
v0.8.5: Check-CA actually checks Windows now (follow-up to #13)
User on issue #13 reported that even after installing the CA (and seeing it in the Windows cert manager UI), our 'Check CA' button still said 'NOT trusted'. Root cause: is_ca_trusted() on Windows was just returning false unconditionally — Check-CA has never worked on Windows. Fix: is_trusted_windows() now shells out to certutil: certutil -user -store Root 'MasterHttpRelayVPN' certutil -store Root 'MasterHttpRelayVPN' Checks both the user store (where our install_windows puts it by default) and the machine store (fallback path when user-store install is blocked). Requires certutil to print the cert name in stdout AND exit 0 — belt-and-suspenders against locales where certutil exits 0 even on an empty match. Also made the Check-CA UI message point users at the CA file path for cross-device install — the same user reported their Android V2rayNG client getting cert errors on our MITM-signed TLS leaves, which is the expected 'the phone doesn't trust our CA' scenario. The message now calls out the ca.crt path explicitly, and notes the Android 7+ user-CA restriction (Firefox Android works, Chrome and most apps don't trust user-installed CAs regardless). Not addressed (by design): - Replacing our CA keypair with Python-generated PEM fails to parse via rcgen. User tried this as a workaround before reporting. rcgen expects PKCS#8 PEM; Python's cryptography commonly emits PKCS#1 ('BEGIN RSA PRIVATE KEY'). Even if parsing worked, mixing an external CA with our leaf-issuing code would break the key match. Users should stick with our generated CA — that's the supported flow. The Python cross-contamination experiment is expected to fail; we don't document it as supported. |
||
|
therealaleph
|
790212cf51 |
v0.8.4: config load failures are no longer silent (diagnoses the reset-on-reopen bug)
A user reported that after Save-config, closing the UI, and reopening,
every form field was blank — but the config.json on disk still had all
the right values.
The culprit in the UI was load_form()'s swallow-errors pattern:
let existing = if path.exists() {
Config::load(&path).ok() // .ok() threw away the error
} else { ... };
if let Some(c) = existing { /* populate form */ } else { /* defaults */ }
When Config::load returned an Err, .ok() silently converted to None,
the form went back to defaults, and the user had no signal at all
that the load had failed or WHY. On every platform I could test
(macOS / Linux) the round-trip works fine with a real round-trip test
added in config.rs (config::rt_tests::round_trip_all_current_fields
and round_trip_minimal_fields_only — both green). So whatever's
failing for this specific reporter is environment-specific (weird
filesystem encoding, partial write, different field shape from an
older version, … TBD). Without visibility we can't diagnose it.
Changes:
1. load_form() now returns (FormState, Option<String>). The String
is a user-facing error message (with the full path + the
underlying parse/validate reason) when Config::load fails on an
existing file.
2. main() plumbs that error into App's initial toast, which sticks
for 30 seconds (vs the normal 5 for regular toasts) so users who
only open the UI briefly still see it.
3. Added tracing::info! in load_form for the success path too —
the Recent log panel now always shows either 'config: loaded OK
from <path>' or 'Config at <path> failed to load: <reason>' on
startup, regardless of toast timing.
4. Added two regression-guard tests in config.rs covering the
full-fields and minimal-fields save shapes the UI emits.
Next time a user reports this: they'll have the exact error in the
toast + the Recent log panel, and we can fix the actual bug instead
of shooting blind.
|
||
|
therealaleph
|
5371bfc7d5 |
v0.8.3: UI log panel now captures tracing events + dispatch routing visibility (issue #12)
Two reported issues:
1. Log level in the form had no visible effect — trace produced the
same panel output as warn.
2. upstream_socks5 was reported as never being attempted.
(1) was because the UI binary never installed a tracing subscriber.
Every tracing::info!/debug!/trace! from the proxy was discarded; only
the handful of manual push_log() calls for start/stop/test reached
the 'Recent log' panel. Swapping the log level in the combo-box just
rewrote the config field — nothing consumed it.
Fix: install_ui_tracing() at startup registers a tracing_subscriber
fmt layer with a custom MakeWriter that mirrors each formatted event
line into shared.state.log. Respects RUST_LOG, defaults to 'info'
with hyper pinned to warn so the panel isn't swamped by low-level
HTTP chatter. Now the log level switch actually filters panel
output, and routing decisions show up live.
(2) is a documentation / visibility issue more than a bug. Our
upstream_socks5 routing is intentionally scoped to raw-TCP traffic
(non-HTTP, non-TLS) — HTTPS goes through the Apps Script relay,
which is the whole reason mhrv-rs exists. But without working logs,
it looks like upstream_socks5 is dead code.
Fix: every branch of dispatch_tunnel now emits a tracing::info! that
says exactly which path the connection took and, where applicable,
whether upstream_socks5 was used:
dispatch api.telegram.org:443 -> raw-tcp (127.0.0.1:50529)
dispatch www.google.com:443 -> sni-rewrite tunnel (Google edge direct)
dispatch httpbin.org:443 -> MITM + Apps Script relay (TLS detected)
Combined with (1), users can now see in real time whether their
traffic is hitting upstream_socks5. If it says 'raw-tcp (direct)'
after they set the field, that's evidence of a real bug; if it
never reaches the raw-tcp branch at all, that's the documented
design (HTTPS → Apps Script).
Also per user request, updated README:
- Shields.io badges up top: latest release, total downloads, CI
status, license, stars.
- Short 'Heads up on authorship' note crediting Anthropic's Claude
for the bulk of the Rust port (with the human-on-every-commit
caveat). English and Persian mirrors both have it.
All 37 unit tests pass.
|
||
|
therealaleph
|
e9a973fc0f |
v0.8.2: CA trust — Firefox enterprise_roots + Chrome ~/.pki/nssdb (follow-up to #11)
After v0.8.1 fixed the leaf cert extensions, users reported "still broken" — specifically Firefox showing: "Software is Preventing Firefox From Safely Connecting to This Site. drive.google.com ... This issue is caused by MasterHttpRelayVPN" for HSTS-preloaded sites. That error is Firefox's "MITM detected AND issuing CA isn't in my trust store" path combined with HSTS blocking the normal override button — so users were stuck with no workaround. Real root cause of the "still broken" reports: the CA was making it into the OS trust store (Windows cert store / update-ca-certificates on Linux) but NOT into the browser-specific trust stores that Firefox and Chrome use on every OS. Three additions: 1. Firefox: . For every Firefox profile we find, we now write this pref to the profile's user.js. It tells Firefox to trust the OS CA store, so our already-successful system-level install automatically covers Firefox on next startup. Critical on Windows (NSS certutil isn't on PATH there, so the certutil-based Firefox install never worked). Idempotent — checks for existing pref before writing and leaves a non-matching user value alone. 2. Chrome/Chromium on Linux: install into ~/.pki/nssdb. Linux Chrome uses its own shared NSS DB, independent of both the OS store (populated by update-ca-certificates) AND Firefox's per-profile NSS. Without this, users installed the CA via run.sh, Chrome still refused every HTTPS site, and they spiraled trying to re-install the CA. We now also initialize that DB with if it doesn't exist yet. 3. Refactored the NSS-install path so Firefox and Chrome share a single install_nss_in_dir() helper. Renamed the top-level entry from install_firefox_nss to install_nss_stores to match scope. Locally verified the cert itself is fine — openssl x509 -text shows Version 3, SAN, KeyUsage (critical), ExtendedKeyUsage, and passes. So the leaf is correct; what was failing was the trust-chain validation inside the specific browser because our CA wasn't in THAT browser's trust DB. Upgrade path: download v0.8.2 and run the launcher or `./mhrv-rs --install-cert`. Restart Firefox/Chrome after install — Firefox needs the restart to re-read user.js. |
||
|
therealaleph
|
27cda07f8d |
v0.8.1: fix MITM leaf cert extensions — HTTPS through the proxy now works (closes #11)
Multiple users reported the same thing (issue #11): they trusted the CA, then re-installed it, then deleted and re-generated it, and still every HTTPS site through the proxy failed in the browser. The python version of the same project doesn't have the issue. Root cause: rcgen's CertificateParams::default() produces a minimum-viable x509 cert that does NOT carry: - ExtendedKeyUsage extension with id-kp-serverAuth - KeyUsage extension with digitalSignature + keyEncipherment Modern Chrome / Firefox / Edge / Safari all reject TLS server leaves without those. The CA trust bit didn't matter — the browser's chain validator rejected the leaf itself with NET::ERR_CERT_INVALID before ever consulting the trust store. So 'reinstall the CA' was powerless to help. Fix in src/mitm.rs::issue_leaf: - Set params.extended_key_usages = [ServerAuth]. - Set params.key_usages = [DigitalSignature, KeyEncipherment]. - Backdate not_before by 5 min to absorb clock skew between the MITM process and a slightly-fast client clock. Same fix in the CA's own not_before. Also added src/mitm.rs::tests::leaf_has_serverauth_eku_and_key_usage as a permanent regression guard — it parses the DER with x509-parser and asserts the three extensions are present. Added x509-parser to dev-dependencies (already in the tree transitively via rcgen). Upgrade path for users affected by #11: download v0.8.1, run it. No CA reinstall required — the CA cert itself was fine, only the per- site leaves were broken. Verified end-to-end locally: curl --cacert <ca.crt> -x http://127.0.0.1:... https://httpbin.org/ip curl --cacert <ca.crt> -x socks5h://127.0.0.1:... https://httpbin.org/ip Both return JSON without cert errors, through the Apps Script relay path. 37 unit tests pass. |