mirror of https://github.com/ospab/ostp.git
ospab
8b5c0a3a8c
Elevation belongs to install time. Registering a task that runs elevated is itself privileged, so an unprivileged GUI can only obtain one by raising the very prompt we are trying to remove. There was nowhere to put it: the Windows GUI ships as a portable zip built with --no-bundle, so the project had no installer at all. Adds an NSIS one, whose POSTINSTALL hook registers the task while already elevated. Connecting then prompts zero times. NSIS over WiX because installerHooks is an NSIS feature; the MSI equivalent needs a custom action, which is more bespoke machinery, not less. installMode is perMachine — the default, currentUser, does not run elevated, and the hook would fail exactly as the in-app attempt did. The task's principal is the SID S-1-5-32-545 (BUILTIN\Users) with InteractiveToken rather than the installing user, so a machine-wide install serves every account instead of only whoever ran the installer; the name is localized and would not resolve. %LOCALAPPDATA% in the arguments is left unexpanded for the same reason — Task Scheduler expands it per running user. Also fixes the in-app fallback, which the portable zip still needs and which had never once worked. It trusted the exit code of an elevated schtasks, but -Verb RunAs launches through ShellExecute and a non-elevated parent generally cannot read the child's exit code: $p.ExitCode yields $null, and `exit $null` leaves PowerShell reporting 0 (measured, not assumed). Failure was arriving disguised as success. -Wait does not reliably block either, so deleting the task XML afterwards raced schtasks reading it. It now waits for the task to actually appear before deleting anything, and treats the exit code as advisory except for 1223, a declined prompt, which is worth failing fast on. Corrects one comment that asserted the opposite of the truth: schtasks writes UTF-16 to a console but UTF-8 with no BOM into a redirected pipe, which is the case that matters here. Only the fallback made the path check work at all. wintun.dll rides along as a bundled resource and the hook copies it beside the executables, since the helper loads it with a plain LoadLibrary. The uninstall hook removes both it and the task, so no stale registration is left pointing at a deleted binary. |
||
|---|---|---|
| .. | ||
| hooks.nsh | ||