diff options
| -rw-r--r-- | packages/meshbay-client/src/main.js | 2 | ||||
| -rw-r--r-- | packages/meshbay-node/tests/test_packaging_win.py | 39 | ||||
| -rw-r--r-- | packaging/win/build-win-light.ps1 | 11 | ||||
| -rw-r--r-- | packaging/win/build-win-msix.ps1 | 10 | ||||
| -rw-r--r-- | packaging/win/electron-builder.light.yml | 3 | ||||
| -rw-r--r-- | packaging/win/electron-builder.msix.yml | 20 |
6 files changed, 37 insertions, 48 deletions
diff --git a/packages/meshbay-client/src/main.js b/packages/meshbay-client/src/main.js index 755f1f7..5e00d0b 100644 --- a/packages/meshbay-client/src/main.js +++ b/packages/meshbay-client/src/main.js @@ -1158,7 +1158,7 @@ function registerBridge() { // .light.yml) ships no node-runtime extraResource at all; the renderer // uses this to fall back to the browser-only "create a group" form // instead of the wizard that assumes a local node it can link right there - // (create-group-page.js) -- see C:\Users\admin\devel\light-client.md 5.3. + // (create-group-page.js). // Unaffected off win32 and in dev: only a packaged Windows build can even // be Light, so everything else keeps today's behaviour unconditionally. function hasBundledNode() { diff --git a/packages/meshbay-node/tests/test_packaging_win.py b/packages/meshbay-node/tests/test_packaging_win.py index 877994d..7b44bbe 100644 --- a/packages/meshbay-node/tests/test_packaging_win.py +++ b/packages/meshbay-node/tests/test_packaging_win.py @@ -24,16 +24,14 @@ NSH = CLIENT / "build" / "installer.nsh" MAIN_JS = CLIENT / "src" / "main.js" PRELOAD_JS = CLIENT / "src" / "preload.js" -# The "Light" target: Electron client + UI, no bundled node. See -# C:\Users\admin\devel\light-client.md for the evaluation this implements. +# The "Light" target: Electron client + UI, no bundled node. LIGHT_NSH = CLIENT / "build" / "installer-light.nsh" LIGHT_YML = WIN / "electron-builder.light.yml" BUILD_WIN_LIGHT = WIN / "build-win-light.ps1" BUILD_WIN_COMMON = WIN / "build-win-common.ps1" # The "MSIX" target: same feature set as Full, packaged for Microsoft Store -# submission instead of NSIS. See C:\Users\admin\devel\msix-installer.md for -# the plan this implements. +# submission instead of NSIS. MSIX_YML = WIN / "electron-builder.msix.yml" BUILD_WIN_MSIX = WIN / "build-win-msix.ps1" MSIX_EXTENSIONS_XML = CLIENT / "build" / "appx-extensions.xml" @@ -683,8 +681,7 @@ def test_ffmpeg_bundling_is_the_default_not_opt_in(): # ------------------------------------------------------------------------ -# The "Light" target: Electron client + UI, no bundled node. See -# C:\Users\admin\devel\light-client.md for the evaluation. Weak, text- +# The "Light" target: Electron client + UI, no bundled node. Weak, text- # reading evidence throughout, same reasoning as the rest of this file: # there is no electron-builder/PowerShell/NSIS runner here, and it is the # right kind of evidence for what these guard against -- a config drifting @@ -921,9 +918,9 @@ def test_create_group_page_falls_back_when_no_node_is_bundled(): # ------------------------------------------------------------------------ # The "MSIX" target: same feature set as Full, packaged for Microsoft Store -# submission instead of NSIS. See C:\Users\admin\devel\msix-installer.md for -# the plan. Unlike Light, this target keeps the node runtime and both -# service scripts -- what changes is packaging format, not what ships. +# submission instead of NSIS. Unlike Light, this target keeps the node +# runtime and both service scripts -- what changes is packaging format, not +# what ships. # Weak, text-reading evidence throughout, same reasoning as the rest of # this file: there is no electron-builder/appx runner here either. # ------------------------------------------------------------------------ @@ -931,9 +928,9 @@ def test_create_group_page_falls_back_when_no_node_is_bundled(): def test_msix_config_is_standalone_and_keeps_the_full_bundle(): """ Unlike Light, MSIX ships the same node-runtime/ffmpeg/service scripts as - Full -- an AppX install never elevating (msix-installer.md 4) is not a - reason to drop the daemon, only to change how its two elevated - operations get triggered (see the two tests below). --config still + Full -- an AppX install never elevating is not a reason to drop the + daemon, only to change how its two elevated operations get triggered + (see the two tests below). --config still means this file is read alone (app-builder-lib's getConfig), so it cannot silently inherit Full's package.json build.nsis or any signing config meant for NSIS. @@ -979,11 +976,11 @@ def test_msix_declares_no_csc_on_purpose(): No certificateFile/certificateSubjectName/certificateSha1 anywhere in this config -- per app-builder-lib's own windowsSignToolManager.js, an AppX target built with no certificate configured is logged as "Windows - Store only build" and left unsigned; Microsoft signs it at publish time - (msix-installer.md 3). Configuring a cert here would be wasted work, not - extra safety, and would risk this target picking up whatever might one - day be configured for Full's NSIS signing if it were ever added to this - file instead of package.json's own build.win. + Store only build" and left unsigned; Microsoft signs it at publish + time. Configuring a cert here would be wasted work, not extra safety, + and would risk this target picking up whatever might one day be + configured for Full's NSIS signing if it were ever added to this file + instead of package.json's own build.win. """ yml = MSIX_YML.read_text(encoding="utf-8") for forbidden in ("certificateFile", "certificateSubjectName", "certificateSha1"): @@ -993,10 +990,10 @@ def test_msix_declares_no_csc_on_purpose(): def test_msix_declares_the_network_capabilities_firewall_ps1_would_add(): """ Matches firewall.ps1's own rules, which are `-Profile Any` (private AND - public network) -- msix-installer.md 8's #1 open item: whether Windows - actually auto-exempts a full-trust packaged app on the strength of - these declarations is unverified until sideloaded, but the declaration - itself must at least match what the elevated NSIS path grants today, or + public network). Whether Windows actually auto-exempts a full-trust + packaged app on the strength of these declarations is unverified until + sideloaded, but the declaration itself must at least match what the + elevated NSIS path grants today, or an MSIX install would be silently narrower than Full/Light. """ yml = MSIX_YML.read_text(encoding="utf-8") diff --git a/packaging/win/build-win-light.ps1 b/packaging/win/build-win-light.ps1 index 5a8a06e..8b2d807 100644 --- a/packaging/win/build-win-light.ps1 +++ b/packaging/win/build-win-light.ps1 @@ -6,12 +6,11 @@ .DESCRIPTION The counterpart of build-win.ps1 (Full) for anyone who only wants to *use* MeshBay -- join groups, chat, browse, download, stream, cast -- - without ever hosting content from this machine. See - C:\Users\admin\devel\light-client.md for the evaluation this - implements: a member never needs a local node to begin with (identity - keys are per node -- the *host's* node, not the joiner's), so Light is - the existing browser-only usage pattern wrapped in the Electron shell, - minus the frozen meshbay-node.exe / ffmpeg / autostart bundle. + without ever hosting content from this machine. A member never needs a + local node to begin with (identity keys are per node -- the *host's* + node, not the joiner's), so Light is the existing browser-only usage + pattern wrapped in the Electron shell, minus the frozen + meshbay-node.exe / ffmpeg / autostart bundle. Steps 1-4 are identical to build-win.ps1 (build-win-common.ps1). Step 5, PyInstaller freezing a node runtime, does not happen at all -- that is diff --git a/packaging/win/build-win-msix.ps1 b/packaging/win/build-win-msix.ps1 index 9f7f667..2aeb2b8 100644 --- a/packaging/win/build-win-msix.ps1 +++ b/packaging/win/build-win-msix.ps1 @@ -4,15 +4,14 @@ + ffmpeg), packaged for Microsoft Store submission instead of NSIS. .DESCRIPTION - See C:\Users\admin\devel\msix-installer.md for the plan this implements. Unlike Light, this target does NOT drop anything from Full's feature set -- it exists because Store certification of the NSIS "MSI/EXE" submission failed for a reason MSIX sidesteps entirely (an unsigned, internet-downloaded installer never gets a chance to run under - Microsoft's own unattended validation bot; see msix-installer.md §2), - not because the bundled node/service-mode/autostart machinery needed - removing. The one real change is *when* the two elevated operations - (firewall rule, service-mode install) can happen: an AppX/MSIX install + Microsoft's own unattended validation bot), not because the bundled + node/service-mode/autostart machinery needed removing. The one real + change is *when* the two elevated operations (firewall rule, + service-mode install) can happen: an AppX/MSIX install never elevates, so neither can run at install time the way build/installer.nsh's customInstall macro does. Both already have an elevation path that does not depend on the installer at all -- @@ -126,7 +125,6 @@ if ($pkg) { Write-Host "OK package: $($pkg.FullName)" -ForegroundColor Green Write-Host (" ({0:N0} MB)" -f ($pkg.Length / 1MB)) Write-Host " unsigned by design -- Microsoft signs it at publish time" -ForegroundColor DarkGray - Write-Host " (msix-installer.md 3)." -ForegroundColor DarkGray } else { Write-Host "!! no *.appx found in $Client\dist-msix" -ForegroundColor Red diff --git a/packaging/win/electron-builder.light.yml b/packaging/win/electron-builder.light.yml index 155ffa6..502a3c5 100644 --- a/packaging/win/electron-builder.light.yml +++ b/packaging/win/electron-builder.light.yml @@ -10,9 +10,6 @@ # Invoked from packages/meshbay-client (see build-win-light.ps1), so every # relative path below resolves the same way package.json's `build` field's # already do. -# -# See C:\Users\admin\devel\light-client.md for the evaluation this -# implements. appId: org.meshbay.client.light productName: MeshBay Light diff --git a/packaging/win/electron-builder.msix.yml b/packaging/win/electron-builder.msix.yml index 5e45598..5460267 100644 --- a/packaging/win/electron-builder.msix.yml +++ b/packaging/win/electron-builder.msix.yml @@ -1,9 +1,8 @@ # Standalone electron-builder config for the "MSIX" Windows target: same # feature set as Full (bundled node + ffmpeg), packaged for Microsoft Store -# submission instead of NSIS. See C:\Users\admin\devel\msix-installer.md for -# the plan this implements -- read that first, especially §4 (why the -# installer can carry none of installer.nsh's elevation logic: an AppX/MSIX -# install never elevates, by design) and §8 (what is still unverified here). +# submission instead of NSIS. The package carries none of installer.nsh's +# elevation logic: an AppX/MSIX install never elevates, by design. What is +# still unverified here is called out at each declaration below. # # Deliberately NOT layered onto package.json's `build` field, same reasoning # as electron-builder.light.yml: --config reads ONLY this file, so nothing @@ -22,8 +21,8 @@ # windowsSignToolManager.js (computePublisherName), an AppX target built # with no certificate configured is logged as "Windows Store only build" and # left unsigned, with `publisher` written into the manifest as-is. Microsoft -# signs the package itself at publish time (msix-installer.md §3) -- signing -# it here first would be pointless work, not extra safety. +# signs the package itself at publish time -- signing it here first would be +# pointless work, not extra safety. appId: org.meshbay.client productName: MeshBay @@ -102,9 +101,9 @@ appx: # firewall.ps1's own rules, which are `-Profile Any` (private AND public # network). Whether Windows Firewall actually auto-exempts a full-trust # packaged app on the strength of these declarations -- eliminating the - # elevation firewall.ps1 exists for entirely -- is msix-installer.md §8's - # #1 open item: verify live before relying on it, the declaration alone - # only proves the manifest is well-formed. + # elevation firewall.ps1 exists for entirely -- is an open item: verify + # live before relying on it, the declaration alone only proves the + # manifest is well-formed. capabilities: - internetClientServer - privateNetworkClientServer @@ -116,7 +115,6 @@ appx: # switch to point it at a different bundled exe). build/appx-extensions.xml # declares that extension by hand for exactly this reason. Whether # Windows actually launches a *non-primary* bundled exe through this - # mechanism is the other open item in msix-installer.md §8 -- untested - # until sideloaded. + # mechanism is the other open item -- untested until sideloaded. customExtensionsPath: build/appx-extensions.xml showNameOnTiles: false |