Upgrade clash_verge_service_ipc and bundled service downloads to v2.7.2,
which labels runtime-installed executables before publication and repairs
existing core labels instead of timing out waiting for service IPC.
Register persistent bin_t rules for production and development service
binaries and cores in the RPM post-install script. Support older semanage
versions, apply rules to existing directories, and warn when optional
SELinux tools are unavailable.
Refs: #7965
The service installer now admits the staged core copies through Windows
Firewall, so TUN system/mixed stacks pass traffic in service mode again
without users re-allowing the new path by hand.
Refs #7915
* feat(service): hand upgraded cores to the service through the installer
The service now only executes administrator-staged core copies, so an
in-app core upgrade has to deliver the new bytes there before the
restart asks for them; otherwise a service-mode restart keeps running
the previous core while the UI reports the new version.
After publishing the downloaded core, service-mode upgrades invoke the
elevated service installer with --install-core <path> --sha256 <hex>.
The digest is computed over the published file and rides the elevated
command line, which no other local account can alter, so a file
swapped after hashing is refused rather than staged. Sidecar-mode
upgrades run the file directly and prompt for nothing.
Rollback distinguishes staging that never ran, was refused, or
succeeded: only a successful staging obliges the rollback to restore
the approved copy too (deliberately not gated on the running mode,
which reads NotRunning after the very crash being rolled back), and a
refused staging restores the file so a retry does not see the new
version on disk and conclude there is nothing to do.
Requires clash-verge-service-ipc >= 2.6.7. The pinned dependency and
the packaged service release must move together with this change, or
the old installer silently treats --install-core as a plain install.
* feat(installer): attest bundled cores to the service at install time
prebuild computes sha256 digests of the downloaded mihomo sidecars
into packages/windows/core-hashes.nsh (gitignored), included through
the NSIS installerHooks path. After unpacking and before starting the
service, the installer stages both cores into the service's approved
directory with those digests, so what gets attested is exactly what
this installer shipped: a core swapped on disk in a user-writable
install directory is refused, not published. Failure is logged and
does not abort the install; a later elevated service install can
stage the cores again.
* chore(deps): require clash-verge-service-ipc v2.6.8
v2.6.8 is the first service whose installer understands
--install-core --sha256; the staging this branch introduces is inert
against anything older, because the old installer treats the flag as a
plain service installation and reports success. The service release and
this pin therefore have to ship in the same app release.
* fix(service): heap-allocate the core hashing buffer
clippy::large_stack_arrays denies the 64 KiB stack array.
* refactor(log): migrate logging to tracing-estuary pipeline
Swap flexi_logger + clash-verge-logger wiring for the tracing-estuary
crate: buffered file sink with explicit panic/exit drains, live level
switching, and tokio-trace/chrome-trace behind crate features.
AsyncLogger moves in-house (VecDeque ring); file format and rotation
stay unchanged.
* fix(log): reset sidecar writer in place and re-pin service-ipc v2.6.7
Rebuilding the sidecar FileLogWriter on config changes leaked flexi's
unstoppable flusher thread plus an fd each time; the writer is now flushed
and reset in place, matching what the service crate does.
get_clash_logs_by_service drops the CompactString conversion layer now that
service-ipc v2.6.7 returns plain Vec<String>, and AsyncLogger is renamed
LogRing to match.
* refactor(log): span-based observability and log noise cleanup
Instrument spans carry the structure flat lines never could: the core-start
spine (mode, readiness/owner generations, pid, config file), proxy apply and
clear routes with guard generations, service IPC sessions with refusal codes
and outcomes, profile-switch terminal outcomes, subscription fetch strategies,
core upgrades with per-proxy version probes, backup flows, timer tasks, config
generation uids, and the startup setup flow; running-mode changes emit one
guarded transition event each.
~90 hand-written noise lines are gone or demoted (entry+success pairs, polled
getter echoes, phase brackets, window sub-steps, platform install chatter);
errors keep their anyhow chain, operation name, and item id, and swallowed
retry results surface per attempt.
Locks both sides to upstream main 17c7757: the WS channel now uses a
single Json transport (connections wire shrinks ~3.4x) and count-stream
error frames are forwarded unchanged; JS/Rust API surfaces stay
identical, so upper-layer code is untouched except the card below.
The home Active Connections card now subscribes to the count-only
ws_connections_count stream instead of parsing the full connections
snapshot every second; the full stream runs only while the Connections
page is mounted.
Drive the production home traffic graph through embedded WebDriver in an
isolated optimized measurement build. Record attributed WebContent and main
process CPU/RSS distributions across foreground, hidden and restored phases.
Keep replay, raw reports, independent-run comparison, cleanup checks and
focused validation available through project commands. Normal release builds
exclude the automation service and measurement entry points.
* fix(sysproxy): gsettings command is no longer mandatory on KDE desktop
* chore(tauri): update sysproxy dependency to use main branch
* chore(deps): update clash_verge_service_ipc to v2.6.6
* docs(changelog): add KDE proxy setting support note
* fix: Gemini test
* naming unlock
* test type
* refactor: deduplicate media unlock checks
* fix: run media unlock checks individually
* fix(media-unlock): satisfy clippy const lint
* fix: stream media unlock test results
* fix: streamline media unlock checks
* fix: force HTTP/1 for media unlock checks
* fix: limit concurrent media unlock checks
* feat: allow concurrent media unlock item checks
mihomo's updater truncates its own running executable in place; macOS kills
that under Hardened Runtime and leaves a 0-byte core. Verge now downloads the
release, verifies a staged copy next to the target, and renames it into place,
which never touches the inode the running core executes from.
Closes#6834
* fix(cmd): preserve anyhow context in coded errors
Use alternate error formatting so coded failures retain the full anyhow context chain without changing their wire format.
* fix(macos): skip redundant proxy disable writes
When both proxy modes are off, read macOS state first and skip networksetup if the OS is already clean. Update the guard target only after a successful write.
* feat(proxy): classify system proxy failures
Attach stable, actionable proxy failure codes to anyhow chains while preserving the original diagnostic causes.
* feat(cmd): return structured command failures
Replace encoded error strings with serializable code and detail fields, and update frontend notice consumers to handle the structured shape.
* fix(scripts): use the js-yaml namespace import
Import js-yaml through its ESM namespace so the i18n cleanup script can access load and dump.
* feat(proxy): localize classified proxy failures
Map privilege and direct-fallback codes to localized explanations, and let mapped causes outrank generic operation keys in notices.
* fix(ui): bound notice text and render failure details
Limit resolved notice text without truncating clipboard content, and normalize structured failures embedded in translation parameters.
* feat(proxy): persist unseen proxy failures
Store unresolved classified failures by code, notify the frontend when the table changes, and show each failure sequence once when a visible window can receive it.
* feat(proxy): report tray and hotkey toggle failures
Record classified failures from tray and hotkey proxy toggles so they appear when a visible window is available.
* fix(ui): restore the proxy switch after failed toggles
Refresh frontend proxy state after a failed toggle so the switch reflects the rolled-back configuration.
* feat(proxy): stop the guard after repeated failures
Report guard outcomes, stop after the failure threshold, and persist the classified failure for the frontend.
* fix(macos): preserve proxy during service handoff
Stop a sidecar being handed to the service without clearing proxy state that the new owner must inherit.
* feat(macos): classify misplaced sidecar state
Distinguish a refused sidecar proxy write from a machine that still needs the privileged service installed.
* feat(ui): recover misplaced sidecar notices
Offer a restart action for macOS proxy failures caused by a ready service while the core still runs as a sidecar.
* feat(ui): install the service from proxy notices
Let privilege notices install the macOS service, restart the core, and report the runtime mode that was actually reached.
* feat(cmd): attach requested proxy operations
Carry the requested proxy direction with structured command failures when the originating command knows it.
* feat(sysproxy): drain guards before OS access
Wait for the local proxy guard to stop before OS reads, service handoff, or final writes, and refuse transitions when it does not drain.
* feat(sysproxy): recover partial proxy writes
Use write progress to choose whether to restore the old guard or compensate with a disabled proxy state, while preserving actionable errors.
* feat(sysproxy): skip already-applied proxy writes
Compare macOS proxy snapshots with global, PAC, and disabled targets so matching state avoids redundant privileged writes.
* feat(proxy): report background proxy failures
Persist and surface classified proxy failures from lifecycle paths that have no direct caller awaiting the result.
* feat(ui): move proxy recovery into a dialog
Guide users through installing or switching to the service after a refused proxy write, and suppress duplicate toast reports.
* fix(ui): close proxy dialog after service recovery
Dismiss the recovery dialog once the core reaches service mode, even when the original proxy request remains pending.
* feat(ui): retry proxy request after service recovery
Replay the requested proxy direction after the core reaches service mode, while leaving incidental restores unchanged.
* fix(proxy): refresh state after successful apply
Publish the proxy refresh from the shared apply path after releasing the lifecycle lock, and remove the tray-specific duplicate.
* feat(ui): show proxy recovery progress
Display installation, restart, and proxy-apply stages while keeping the primary action spinner visible during recovery.
* feat(ui): route unavailable TUN through service recovery
Let the TUN switch request service recovery and restore its requested state after the core restarts in service mode.
* fix(ui): avoid duplicate TUN recovery errors
Roll back deferred TUN toggles without reporting an error, and publish configuration refreshes from the transaction commit path.
* chore: update changelog & pinlock
* fix(core): resolve platform-specific clippy warnings
* fix(core): detect Windows wildcard TCP conflicts
Windows permits a specific exclusive bind beside an existing non-exclusive wildcard listener. Consult the system TCP listener table so the probe reports that overlap as a conflict.
* feat(layout): add logging of MihomoWebSocket instances in dev mode
* refactor(hooks): defer ws assignment in use-mihomo-ws-subscription
* chore: update tauri-plugin-mihomo-api dependency source to use github protocol
* docs: update changelog with websocket connection fix
* fix(core): put the user's node choices back when the core starts
mihomo restores the node picked in each group from the `cache.db` it keeps
in the directory it was started against. The app relied on that entirely,
and it does not hold: `profile.store-selected` comes from a merge template
a user is free to replace, and a service older than the durable runtime
generation starts every core in a directory nothing has ever run in. Both
end the same way — every `select` group falls back to the first entry in
its `proxies:` list.
The app already knows better. It records each selection in the profile,
and `activate_selected_nodes` already reconciles that record against the
running core — it was only ever called when switching profiles, never when
a core came up. Call it from the three places a core process becomes
ready. Repeat calls supersede each other, so no coordination is needed
between the start paths.
That makes the profile authoritative, which turns any selection it does
not know about into one the next start silently undoes. The chain proxy
moved a group without recording it, so recording is now one shared hook
that both it and the proxy list go through.
Restoration is spawned, not awaited: it polls the core until its groups
are readable, and a start must not wait for that.
* fix(tray): record the node the tray switched to
Restoring the profile's selections when a core starts made the profile
authoritative, which turns any selection it never learned about into one
the next start silently undoes. The proxy list and the chain proxy both
record; the tray did not.
So switching node from the tray survived only until the next restart, and
then reverted to whatever the profile last knew — a regression the
restoration itself introduced, and only for the tray.
`record_selected_node` is the backend counterpart of the frontend's
`useRecordSelection`. Failing to record does not fail the switch: the core
is already on the new node by then, and reporting the switch as failed
would be wrong. It is logged instead.
* fix(core): restoring selections must not prune what the core has not loaded
Putting the profile's selections back when a core starts reused the
reconciliation written for profile switches, and that one also *repairs*:
a record whose group is absent from two snapshots a second apart is
dropped, and the reduced list is written to profiles.yaml.
After a profile switch the configuration is loaded, so absence is
evidence. After a core start it is not — a provider-backed group can be
empty or missing for seconds — and a record pruned on that evidence is
gone for good, because the provider finishing later cannot bring it back.
Restoring now keeps the records and only applies what it can match;
pruning stays with the caller entitled to conclude it.
The restore is also asynchronous: it reads the profile, polls the core
until its groups are readable, then puts its selections. A choice the user
makes inside that window is newer than what it captured, so letting it
finish pushed the core back to the older node while the profile already
held the newer one. Recording a selection now supersedes any activation in
flight — from the tray, and from the UI and chain proxy through
`patch_profile`.
* fix(core): activate the selections of the profile that is actually running
The activation worker read the profiles draft. A profile switch stages its
target there before validating it, so a switch that fails — leaving the
previous profile running — could still have handed an activation the
rejected profile's selections, which it would then apply to whichever
same-named groups the running profile has.
Reading the committed state removes the window. The switch that succeeds
commits before it activates, so nothing changes for that caller; what
changes is that a restore running at core start can no longer observe a
switch that never happened.
* fix(core): stop a restoration from undoing a choice made while it runs
Two gaps in making the profile authoritative, both found by adversarial
review of the commits that introduced it.
A restoration reads the profile's selections once, then polls the core
until its groups can be read — seconds, on a cold start. A selection made
inside that window is newer than what the restoration is carrying, and
nothing told the restoration so: it went on to apply the older choice over
the user's. The UI accepted the new node and traffic snapped back to the
old one, with the profile and the running core then disagreeing. Recording
a selection now abandons any restoration still in flight, through the same
generation counter every other superseding caller uses.
The other gap is the home card in global mode, which passed
`skipConfigSave` and so recorded nothing. That was harmless while nothing
re-applied the profile; now it means the next start undoes the choice. It
was the only caller that ever set the flag, so the flag is gone rather than
flipped — a parameter whose one use was a bug is not worth keeping.
* fix(core): wait for the selections that can be put back, keep trying for the rest
Two gaps in restoring the profile's selections when a core starts, both
found by adversarial review.
Restoring re-checked once, a second later, and stopped. That is enough
after a profile switch, which happens with the configuration already
loaded. A core start is the opposite case: a provider-backed group is
present but empty until its provider finishes loading, and a `select` can
fail while the core is still settling. Neither produces an activation, so
the restore reported success having applied nothing and the group stayed
on the first entry of its `proxies:` list — the outcome restoring exists
to prevent. It now keeps looking, on a deadline, at what the core is
actually on rather than at what it managed to send.
Restoring was also spawned, and the caller enables the system proxy the
moment the start returns — so traffic could be pointed at a core still on
the wrong node. The first pass is now awaited, bounded, and the rest keeps
settling in the background: a core that will not answer delays a start
rather than blocking it, because being proxied through the wrong node
beats not being proxied at all.
TUN is deliberately not covered, and cannot be by anything here: it is
configured in the core's own file, so it carries traffic from the moment
the process starts. What puts a TUN user on the right node from the first
packet is the core's own `cache.db`, which is why the service keeps an
owner's runtime generation across restarts.
`supersede_selected_activation` and `cancel_selected_node_activation` were
the same function under two names, added independently for the same
reason, and `patch_profile` called both. One survives, called once, after
the profile is written — the only placement that needs to exist, since an
activation that read the older profile is cancelled by it and one starting
afterwards reads the newer one.
* fix(core): record a selection by naming it, not by resending the list
Recording a node selection sent the whole selection list, built from the
profile the frontend had rendered. Two selections made before that list
refreshed were therefore built from the same stale snapshot, and the later
write dropped the earlier group's choice. Since a core start re-applies
whatever the profile holds, the dropped one came back on the next restart
— the profile and the running core disagreeing, in the direction the user
would least expect.
The tray already avoided this, because it went through
`record_selected_node`, which merges one group into the profile inside
`with_data_modify`. Exposing that as a command and pointing the frontend
at it leaves one way to record a selection instead of two, and removes the
list from the wire: what a caller knows is the group and the node, and
that is now all it says.
`useRecordSelection` no longer reads the profile at all, which also makes
it stable across renders rather than changing identity whenever the
profile does.
* test(core): make every way of declining to stage answer for itself
`CoreRestarted` was added to `StageRejection` upstream and reached
production without a test. It inherited the right verdict — every
`RestartRequired` is matched together — but nothing said so, and nothing
would have noticed if it had inherited the wrong one.
The list of rejections now goes through a wrapper whose `match` is
exhaustive, so the next variant added upstream fails to compile here. That
is the part worth having: it does not prove the list is complete, but it
does mean nobody can add a way to decline without being sent to this test
to say what it should lead to.
* build(deps): pin the service protocol to v2.6.1
The pin tracked `feat/stage-runtime` because the protocol change it
carried had no tag yet. It has one now, and a branch pin makes the build
irreproducible: an upstream force-push silently changes what this
compiles against.
v2.6.1 carries the runtime generation an owner keeps across restarts,
which is what lets the core hold on to the `cache.db` its node selections
and fake-ip leases live in. The protocol itself is untouched — epoch,
revision and both compatibility floors are byte-identical to v2.6.0 — so
this is a fix release in both directions: an older service still works
with this app, and this app still works with an older service, only
without the durable generation.
The lockfile change is the two lines that name it. Reaching for
`cargo update -p` instead re-resolved a subtree and quietly downgraded
`windows-sys`, `windows-core` and `getrandom` along the way.
wonfen