Foreground the Windows Hello consent dialog (v0.2.8)#203
Merged
Conversation
The consent prompt is requested by gocode-dev's windowless, detached secret agent, so `UserConsentVerifier::RequestVerificationAsync` (no HWND) shows the "Windows Security" / Hello dialog *behind* the user's active window — they have to hunt for it before they can authenticate. Use the HWND-aware interop variant instead: create a transient, top-most, invisible owner window, bring it to the foreground (AttachThreadInput to defeat the foreground lock), and pass its HWND to `IUserConsentVerifierInterop::RequestVerificationForWindowAsync` so the dialog inherits foreground activation by construction. Because the dialog is then modal to a window on our thread, that thread must pump messages while awaiting the result — a blocking `.get()` deadlocks — so we pump via MsgWaitForMultipleObjectsEx until the async op completes. Any failure in the windowing / interop path falls back to the original windowless `RequestVerificationAsync`, so foregrounding can never block a credential decrypt. Scoped to the `hardware-enclave` Windows backend (`internal/windows`); the legacy parallel `enclaveapp-windows` copy is left untouched and can be synced separately. Adds the `Win32_System_WinRT` feature (home of `IUserConsentVerifierInterop`); `AttachThreadInput` is already covered by `Win32_System_Threading`. Bumps the workspace to 0.2.3. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
6c78dcc to
a3aaaf5
Compare
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
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.
Problem
gocode-dev's secret agent is a windowless, detached background process.
UserConsentVerifier::RequestVerificationAsync(no HWND) therefore shows the Windows Hello / "Windows Security" dialog behind the user's active window — they have to find and click it before authenticating, and it feels like a stall.Fix
Use the HWND-aware interop API
IUserConsentVerifierInterop::RequestVerificationForWindowAsyncwith a transient, top-most, invisible owner window we create and bring to the foreground (AttachThreadInputto defeat the foreground lock). The dialog inherits foreground activation by construction — no polling for the dialog window, no guessing its class.Because the dialog is then modal to a window on our thread, that thread must pump messages while awaiting the result (a blocking
.get()deadlocks — confirmed empirically). We pump viaMsgWaitForMultipleObjectsExuntil the async op completes.Safety: any failure in the windowing/interop path falls back to the original windowless
RequestVerificationAsync, so foregrounding can never block a credential decrypt.Scope
crates/hardware-enclave/src/internal/windows/foreground_window.rs(new) — RAII owner window + message pump.…/hello_gate.rs—prompt_user_consentsplit into foreground / windowless-fallback / result-interpretation.Win32_System_WinRTfeature (home ofIUserConsentVerifierInterop);AttachThreadInputalready covered byWin32_System_Threading.enclaveapp-windowscopy is intentionally left untouched (not consumed by gocode-dev); can be synced separately.Testing
Validated end-to-end on Windows 11 via gocode-dev (patched to this branch): the Hello dialog now appears foregrounded/focused, no hang, and the foreground path adds ~23ms (the residual prompt latency is CredentialUIBroker + the biometric sensor, unchanged).
cargo fmt,clippy --all-targets -- -D warnings, andhello_gatetests pass locally.🤖 Generated with Claude Code