The mipsel-unknown-linux-musl job in v0.4.2-beta.2 failed at "Install cross":
cross-rs's own source uses a macro-at-end-of-block pattern (eyre::bail!())
that trips rustc's semicolon_in_expressions_from_macros lint on current
toolchains. `cargo install` compiles the installed package as the "local"
crate, so Cargo's usual automatic lint-capping for dependencies doesn't
apply to cross's own code - and other cross-built targets in the same run
(armv7, aarch64-linux, i686-linux) succeeded, so this reads as a race
against cross-rs's unpinned `main` branch history (no --rev/--tag) rather
than a deterministic break.
RUSTFLAGS="--cap-lints=warn" is the standard mechanism for exactly this
situation - building a third-party tool against a newer compiler than its
own lint config assumed - without touching our own build's lint levels.
More robust than pinning to one historical commit, which just relocates
the same risk to whenever that pin is next updated.
scripts/gha.ps1's -Branch ValidateSet accepted 'pre-release' and would
`git checkout pre-release` to promote alpha, but no such branch has ever
existed in this repo — only `beta` does (confirmed: `git branch -a`, and
the existing 0.4.6-beta/0.4.7-beta release history was cut from `beta`).
The very first beta release under the new gha.ps1 versioning scheme would
have failed outright on the checkout step.
This naming mismatch had spread through the whole release surface:
- scripts/gha.ps1: -Branch ValidateSet + all internal checks
- .github/workflows/release.yml: a dead branch-name check (harmless only
because the workflow currently triggers on tag-push, not branch-push)
plus two comments
- CONTRIBUTING.md / .ru.md: branch-strategy table documented a
`pre-release` branch that doesn't exist
- README.md / .ru.md and ostp/src/main.rs: the `ostp update -b <name>`
CLI help text/docs
- scripts/install.sh: the channel match the CLI flag feeds into
Renamed all of it to `beta` to match the branch that actually exists.
Left scripts/gha.ps1:21's "semver pre-release identifier" alone — that's
the generic semver spec term, unrelated to the branch name, and got
reverted after a blanket replace briefly clobbered it.
Note: install.sh's alpha/beta self-update paths still assume a rolling
GitHub release tagged literally "alpha"/"beta" exists, which no gha.ps1
release ever publishes (only versioned tags like v0.4.7-beta.3) - that's
a separate, real bug, tracked apart from this rename since fixing it needs
either a floating tag from gha.ps1 or an API-query rewrite of install.sh.
resolve-channel treated EVERY v* tag as stable, so v0.4.6-beta got published
as a non-prerelease "Latest" release, sitting on top of the release line. Now
a pushed tag is used as-is and its suffix decides the channel: v*-alpha / v*-beta
are prereleases, only a bare vX.Y.Z is stable. (A tag is never recomputed from
Cargo.toml, so the release can't upload to a different tag than the one pushed.)
Version bumped 0.4.5 -> 0.4.7 (0.4.6 is already taken by the mislabelled beta).
This commit's tip is what gets tagged v0.4.7-beta to cut the beta build.
The run-name expression contains the GHA string literal 'Release build: {0}'
— an unquoted YAML plain scalar treats ": " as starting a nested mapping,
which invalidated the entire workflow file at parse time (before any job
runs). Every push since that line was introduced failed instantly with
"Invalid workflow file ... line 11", silently burning an Actions-minutes
run each time for nothing. Wrapping the whole expression in double quotes
fixes it — verified with `npx js-yaml` that the file now parses and the
run-name value round-trips intact.
Stable releases were already "vX.Y.Z" (from the actual git tag pushed for
that channel), but nightly/beta tags were bare "X.Y.Z-nightly"/"X.Y.Z-beta"
— inconsistent with the v-prefixed convention used everywhere else. Every
channel's tag now starts with v: "vX.Y.Z-nightly", "vX.Y.Z-beta", "vX.Y.Z".
run-name showed "release version nightly" / "release version pre-release"
for every branch-push run — read exactly like the release TAG was bare
"nightly"/"pre-release" (the bug fixed earlier), when the actual GH Release
tag has been correctly versioned (e.g. "0.4.3-nightly") all along via
resolve-channel. run-name can't reference job outputs (it's evaluated before
any job runs), so it can't show the real computed tag directly — spell out
"channel" instead so the label can't be mistaken for the release tag again.
- GUI launch_as_admin now matches the CLI's UAC diagnosis: detects
ERROR_CANCELLED (1223, user declined the prompt) instead of silently
treating it as success, and reports GetLastError()+exe path for any other
ShellExecuteW failure, replacing the old single opaque "denied or missing"
message that made GUI/TUI failures impossible to tell apart.
- generate-key subcommand renamed to `gk` (kept `generate-key` as an alias).
- Fixed a real short-flag collision: GenerateKey's --count used short='c',
which collides with the global --config short (propagated into every
subcommand); clap validates the whole command tree on first parse(), so
this could break parsing for the entire CLI, not just generate-key/gk.
--count is now short='n'.
- ostp-flutter/pubspec.yaml version was stuck at 0.2.97+12; bumped to 0.4.1+13.
- release.yml: added a resolve-channel job that computes one release tag per
run instead of repeating the logic in five upload steps. Rolling channel
pushes now carry the actual Cargo.toml version instead of a bare channel
name: `{version}-nightly` for the nightly branch, `{version}-beta` for
pre-release. workflow_dispatch gained a `channel` input restricted to
nightly/beta only — a manual run can never accidentally publish a "stable"
release; that still requires an explicit vX.Y.Z tag push.
Brings the useful work from the old master/pre-release lineage (5c2b5a0)
onto the clean rebuild, since that lineage never had the multi-server/WSS/
Reality removal or any of the 0.4.0 stability work. This is a manual port,
not a cherry-pick — this file's Args/ClientConfig shape had already
diverged too much for the patch to apply mechanically.
- ostp/src/main.rs: flat Args -> clap subcommands (setup, init, generate-key,
links, check, connect, uninstall, update, import, proxy-env,
proxy-env-clear), bridged onto the existing ~500 lines of flag-driven
dispatch via a LegacyArgs struct so none of that logic had to change.
- Fixed a real bug found while porting: GenerateKey's `count` used
short='c', colliding with the global `--config` short (also 'c'), which
clap validates across the whole command tree on first parse() -- a
duplicate short flag there could break every subcommand's parsing, not
just generate-key's.
- `update` now takes `-b/--branch` and `-v/--version` explicitly (was a
bare flag with no way to target a channel or exact version).
- Added the UAC elevation step for TUN mode that this lineage's CLI was
completely missing (`run_client_directly` went straight to creating the
TUN adapter unelevated). Also fixed the elevation check itself: it only
tested `ret <= 32`, but ShellExecuteW returns ERROR_CANCELLED (1223) when
the user clicks "No" on the UAC prompt -- > 32, so a denied prompt was
read as success and the process exited silently without starting the
tunnel. Now ret==1223 is reported explicitly, and a genuine failure logs
GetLastError() so the real Win32 cause is visible next time.
- scripts/install.sh: added -b/--branch alongside the existing -v/--version,
and channel-aware release resolution (nightly/pre-release use their own
rolling tag; stable resolves via the GitHub API's "latest").
- release.yml: added nightly/pre-release branch-push triggers for rolling
prereleases. Fixed the tag_name logic from 5c2b5a0, which mapped
`master` pushes to a release tagged "nightly" -- backwards from master
being the most stable channel. github.ref_name already equals the
branch or tag name that triggered the run, so no per-branch remapping is
needed at all; master is intentionally left off the branch-push list --
it only ever gets real version tags.
Verified: `cargo build -p ostp` succeeds, and `ostp update --help` /
`ostp generate-key --help` / `ostp --help` show the expected flags with no
clap panic.
Co-Authored-By: Claude <noreply@anthropic.com>
security / protocol:
- Derive a PER-KEY junk marker (obfuscation.rs, info byte 0x04) instead of the
global constant [0x88,0x1A,0x93,0x5D]. A fixed marker was a universal DPI
signature identifying ALL OSTP users at once — exactly what the HKDF version
gate avoids for the handshake. Server drops junk via a new DispatchOutcome::Junk
inside the existing key-trial loop (secrets already derived → zero extra cost);
client stamps its own key's marker.
- §E: configurable junk/fragmentation params (junk_pc / junk_ps / frag_chunk / frag_sleep).
GUI (desktop):
- Light theme + toggle, GUI version footer in Settings.
- Fix mouse-wheel scroll on Settings (flex child needed min-height: 0).
- Drop the false "process exclusions unsupported in TUN mode" warning — they DO
work (native_handler maps port->process via GetExtendedTcpTable).
release / infra:
- build.ps1: add -PreRelease (tag CURRENT version as v<ver>-beta.N, no bump, no
master commit); guard the panel build when ostp-control ships no source; bump
the real ostp-gui/package.json instead of the nonexistent ostp-control one.
- release.yml: mark hyphenated tags as GitHub pre-releases; don't hard-fail the
web-panel step when there is no source (use committed dist/).
- Versions aligned to 0.4.1; README license badge BSL 1.1 -> AGPL v3.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The "system" TUN stack that shelled out to a bundled tun2socks binary is
long-dead — Flutter already hardcodes the native OSTP stack — and only
bloats the build.
- ostp-jni: drop the tun2socks spawn branch and the tun_child handle;
the native TUN (run_native_tunnel_from_fd) is now unconditional. The
JNI signature is kept ABI-stable (t2sBinPath/localProxy retained but
ignored) to avoid breaking the Kotlin linkage without an Android build.
- Delete the committed 10 MB tun2socks-arm64 asset; drop the tun2socks
download steps from the Android build scripts.
- Remove the dead tun2socks.exe entry from the desktop build_dist.js
(it required a file nothing downloads, breaking the GUI dist build).
- Reword stale tun2socks references in proxy.rs, the GUI config comment,
install.ps1, the release workflow matrix, and CONTRIBUTING.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
TUN Interface:
- Fixed adapter name to always be 'ostp_tun' by cleaning up stale
adapters before launch (prevents 'ostp_tun 2', 'ostp_tun 3', etc.)
- Parallelized route setup with tun2socks launch to save ~3 seconds
- Replaced fixed 2-second sleep with adapter readiness polling
- Added -NoProfile to all PowerShell calls for faster execution
Speed:
- Reduced handshake timeout from 10s to 5s
- Reduced tun2socks spawn buffer from 300ms to 0 (removed)
GUI:
- Added i18n support: English and Russian translations
- Language toggle button in header (EN/RU)
- Merged 'IP Ranges' field into 'Bypass IPs / CIDR Ranges'
- Removed separate IP ranges field
- All static text uses data-i18n attributes
- Status messages, labels, toasts all translated
- Replaced alert() calls with toast notifications
CI/CD:
- Added separate GUI build job for Windows x64 and arm64
- Produces ostp-windows-gui-{arch}.zip with: ostp-gui.exe + wintun.dll + tun2socks.exe
- Uses Tauri CLI v2 for build
build.ps1:
- Added mandatory cargo check pre-flight that blocks releases on errors
- Added --Check flag for check-only mode (no build, no release)
- Reverts version bump if check fails
- Professionalized all output (removed informal language)
- Cleaner output structure with consistent [ok], [warn], [error] tags
install.ps1 / install.sh:
- Professionalized all prompts and messages
- Removed informal phrasing
- Consistent formatting
test_linux.sh:
- Updated all log string matchers to match professionalized output:
'Connection established' (was 'Bridge connection established')
'Starting server' (was 'Starting in SERVER mode')
'Starting client' (was 'Starting in CLIENT mode')
RTT regex updated for new format
release.yml:
- Added cargo check pre-flight step before native compilation
ospab
ospab