diff options
Diffstat (limited to 'packages/meshbay-client/build/installer-light.nsh')
| -rw-r--r-- | packages/meshbay-client/build/installer-light.nsh | 67 |
1 files changed, 67 insertions, 0 deletions
diff --git a/packages/meshbay-client/build/installer-light.nsh b/packages/meshbay-client/build/installer-light.nsh new file mode 100644 index 0000000..86e41ba --- /dev/null +++ b/packages/meshbay-client/build/installer-light.nsh @@ -0,0 +1,67 @@ +; electron-builder NSIS customisation for the "Light" target +; (packaging/win/electron-builder.light.yml's nsis.include). +; +; Deliberately much smaller than build/installer.nsh (Full's): there is no +; bundled node, so there is nothing to autostart, no PATH entry to add, no +; process to stop before overwriting a file, and no boot-time Scheduled Task. +; The only thing this installer does, all conditional on interactive setup +; (never ${Silent}): set up the Windows Firewall rules Light still needs -- +; the client's own WebRTC ICE rule and the two LAN-casting rules (see +; packaging/win/firewall.ps1's own header for why the *client*, not just a +; node, needs an inbound allow). One elevation, no radio page -- there is +; nothing to choose, so unlike Full's installer.nsh there is no mode +; question at all. +; +; Per-user only, same reasoning as Full: the keystore and the DPAPI-protected +; hub device key are bound to the signed-in account (MESHBAY_DESIGN.md +; 11.2 / 7.5), and build.win's nsis config forbids elevation at install time. +; +; MUST NOT touch anything a co-installed Full client owns. Full and Light can +; be installed side by side (distinct appId/productName/install dir), and it +; is entirely plausible for a machine to have both -- Light's installer must +; be a no-op with respect to a Full install's node process, its per-user +; Startup entry, its Scheduled Task, and the "MeshBay Node" firewall rule. +; Concretely: this file never stops a process by image name, never touches +; the per-user PATH registry value, never references either of Full's two +; service scripts, and never removes a startup shortcut of its own -- +; test_packaging_win.py pins that absence. + +!include "WinMessages.nsh" +!include "LogicLib.nsh" + +!define MB_PWSH "$SYSDIR\WindowsPowerShell\v1.0\powershell.exe" + +; ── force per-user, skip the all-users / current-user page ────────────────── +; Same as Full's installer.nsh -- see that file's own comment for why. +!macro customInstallMode + StrCpy $isForceCurrentInstall "1" +!macroend + +!macro customInstall + ${IfNot} ${Silent} + ; Unelevated first: Get-NetFirewallRule needs no admin, only New/Remove + ; do, so a repeat/repair install that already has the rules in place + ; raises no UAC prompt. + nsExec::Exec '"${MB_PWSH}" -NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\firewall.ps1" check' + Pop $R0 ; 0 = every rule already present + ${If} $R0 != 0 + ExecShellWait "runas" "${MB_PWSH}" \ + '-NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\firewall.ps1" add' \ + SW_HIDE + ${EndIf} + ${EndIf} +!macroend + +!macro customUnInstall + ; Opt-in, default No -- a stale allow-rule is inert, so this should not + ; nag. A silent uninstall skips it entirely (no UAC prompt of its own). + ${IfNot} ${Silent} + MessageBox MB_YESNO|MB_ICONQUESTION \ + "Remove MeshBay Light's Windows Firewall rules? This needs one administrator confirmation. They are harmless if left." \ + /SD IDNO IDNO mb_keep_firewall + ExecShellWait "runas" "${MB_PWSH}" \ + '-NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\firewall.ps1" remove' \ + SW_HIDE + mb_keep_firewall: + ${EndIf} +!macroend |