fix(client): don't refuse the daemon when launch path != resolved image path (WinGet)#462
Merged
Merged
Conversation
… image path `uffs <anything>` failed with "Daemon identity verification failed … the process on the IPC endpoint does not match the exe hash recorded when the daemon started" on WinGet installs — blocking every search. Root cause: the identity check compares FNV-1a hashes of two path STRINGS produced by different APIs: - daemon records `std::env::current_exe()` (the LAUNCH path) - client reads `QueryFullProcessImageNameW(pid)` (the resolved IMAGE path) For a daemon launched through a symlink/shim — e.g. WinGet's `…\Local\Microsoft\WinGet\Links\uffsd.exe` — those two strings differ for the SAME binary, so the hashes mismatch and the strict check hard-refused the connection. It's a false positive, not impersonation. Fix: treat the path-string hash as a fast-path, not the sole authority. On mismatch, defer to `verify_daemon_identity(pid)` — the peer must be a `uffsd` binary (by name) and, when signed, pass Authenticode. A genuine impostor fails that exactly as it failed the hash, so security is preserved; this just mirrors the existing hash==0 fallback. The two strict-verify tests still pass (their non-`uffsd` test process is refused by the name check). Verified: 204 uffs-client tests green, clippy clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Symptom
On a WinGet install, every
uffs <search>fails:Searches are completely blocked.
Root cause
The identity check compares FNV-1a hashes of two path strings from different APIs:
std::env::current_exe()QueryFullProcessImageNameW(pid)For a normal launch these match. But WinGet exposes the binary through a shim/symlink at
…\Local\Microsoft\WinGet\Links\uffsd.exe, so the daemon records the Links path while the client reads the resolved Packages path — same binary, different strings → hash mismatch → the strict check hard-refused the connection as a suspected hijack. False positive.Fix
Make the path-string hash a fast-path, not the sole authority. On mismatch, defer to
verify_daemon_identity(pid)— the peer must be auffsdbinary (by name) and pass Authenticode when signed. A genuine impostor fails that exactly as it failed the hash, so the security property is preserved; this only stops punishing a legitimate daemon for a path-representation difference. (Mirrors the existinghash == 0fallback.)Tests
The two strict-verify tests still pass — their non-
uffsdtest process is refused by the name-check fallback, so impersonation is still caught. 204uffs-clienttests green, clippy clean.🤖 Generated with Claude Code