meshbay.git/packaging/win, branch 0.20

build: audit the shipped Python dependencies with pip-audit

2026-10-15T12:56:35Z

No lock file pins the dependencies, so each build installs the newest releases and what ships is only known once it has. packaging/audit_deps.py runs pip-audit then: build-common.sh on the venv before stripping it, build-node-runtime.ps1 on the environment before PyInstaller freezes it. A known vulnerability stops the build, unless its id is listed in packaging/pip-audit-ignore.txt with why it does not apply. No network only skips the audit with a warning, as does a pip-audit that cannot be installed or writes no report. pip-audit runs from a venv of its own, never from the one that ships. Our packages are not audited (not on PyPI), nor pip, setuptools and wheel, which do not ship. Checked with the real build-common.sh (79 packages, none known), with PyJWT 2.14 (the build stops on its two advisories, and goes on once they are listed) and offline (a warning, the build goes on). The PowerShell step was not run here. Co-Authored-By: Claude Opus 5.5

fix(packaging): ship only the TMDB token line of QE/default.env

2026-10-15T12:24:25Z

build-node.sh and build-node-runtime.ps1 copied QE/default.env whole into every deb, rpm and Windows build after checking only its first 30 bytes. The file is unversioned and sits beside other QE notes, so any line added to it later would have gone out publicly. Only its first line ships now, and only once it is exactly MESHBAY_TMDB_DEFAULT_TOKEN=; a missing file, a BOM, a token not on the first line or an empty one still stop the build. The Linux step is run by a test against a scratch repo; the PowerShell one has the same rule and was not run here. Co-Authored-By: Claude Opus 5.5

feat(cli): meshbay-cli, a command-line client for members

2026-10-14T20:20:15Z

Signs in to the hub, lists the account's groups and their folders, and downloads and uploads files directly with each group's node, end-to-end encrypted. With no argument it opens a two-pane interactive mode (Textual). Session and device keys are kept encrypted under the system's key storage, or a 0600 key file where there is none; node keys are pinned at first contact; a new machine links as a device. Packaged on its own on Linux (deb and rpm, on meshbay-common's venv, with a man page generated from the parser) and frozen next to meshbay-node in the full Windows installer, not the light one, with a self-test the build runs. client/keys.py ports keyderive.js and is LGPL like it. Co-Authored-By: Claude Opus 5.5

test(node): run the connection processes on Windows, source and frozen

2026-10-12T22:30:39Z

Connection processes and the larger UDP receive buffer were written and measured on Linux; nothing had run on Windows, and `meshbay-node.exe webrtc-worker` had never run from a frozen build on any system. - test_connection_processes.py failed on Windows (8 tests): the selector loop the suite uses there cannot start a process. A test marked `daemon_loop` now runs on the daemon's own loop, chosen through pytest-asyncio's loop factories. - The build starts both frozen executables as connection processes and carries a connection through each (smoke-connection-process.py). The daemon's own smoke test never signs in to a hub, which is when the processes start. - The warning for a receive buffer below what was asked named net.core.rmem_max on every system; it names it on Linux only. Windows grants the 4 MB. Measured on an installed build in service mode, docs/WINDOWS-PORT.md §5.12: two processes at startup and on a live change, a browser's handshake, chat, a 200 MB download over 8 connections across both processes, an upload, a video stream, and stop, restart and start leaving no process behind. Co-Authored-By: Claude Opus 5.5

feat(packaging): the Store package declares what the NSIS scripts do

2026-10-10T07:57:29Z

A test-signed install of the MSIX build, in the WindowsApps folder a Store install uses, showed that every script-made piece of the NSIS model breaks there, because each names the install folder and every update deletes it: the firewall rules went stale, the PATH entries piled up pointing at deleted folders, and the Startup-folder .vbs was refused ("Permission denied") right after sign-in. The network capabilities the manifest declared covered nothing: they make rules for sandboxed apps only, and a listener in the package still got the Windows firewall prompt. The package's own startup task was on by default, started the node whatever mode the Node page said, and ran the console executable, whose window stopped the node when closed. The package now declares what Windows then creates at install, carries across updates and removes with the app, all without an administrator prompt (each measured on the real install, through an update and a reboot): - firewall rules for the node, in a custom manifest template, since only a package-level element can hold them; - the startup task, off by default, running meshbay-nodew.exe, a new build of the daemon without a console; - an execution alias for meshbay-node.exe, so the app adds no PATH entry. The node's CLI switches the startup task (platform.startup_task, ctypes over the WinRT ABI): Windows gives the package's identity to the executables in it, not to a powershell.exe the app starts, which got "Element not found". `meshbay-node autostart install | remove | status` therefore works in the Store package from the app and a terminal alike; the app caches the answer, since the Node page polls. Starting at boot stays the .exe installer's: the Store package offers no service mode, and the CLI refuses `service install` there. Process listings count both image names. The Node page's status poll cleared the message of a refused action within five seconds; the two errors are kept apart now (all Windows builds). Co-Authored-By: Claude Opus 5.5

fix(packaging): ship QE/default.env as is, the one TMDB token source

2026-10-09T16:22:42Z

Both builds copy QE/default.env beside the node and stop without it. No token parsing, no other source, no MESHBAY_ALLOW_NO_TMDB. Co-Authored-By: Claude Opus 5.5

fix(client): remove firewall rules and boot task on uninstall, unasked

2026-10-07T11:48:28Z

The Yes/No before it defaulted to No, so they stayed behind. Read both unelevated and raise the UAC prompt only when one is left. Co-Authored-By: Claude Opus 5.5

chore: license MeshBay — LGPL protocol layer, AGPL for the rest

2026-10-05T07:20:38Z

The protocol layer is LGPL-3.0-or-later in every language it exists in, so any client may use it whatever its own licence: meshbay-common, and the files marked with an SPDX line — keyderive.js, crypto.js, playlist-crypto.js, transport*.js; keyring.js, transcripts.js and argon2-wasm.js on the desktop; Kdf.kt, Keyring.kt and Transcripts.kt on Android. Everything else is AGPL-3.0-or-later, which the RPM specs and package.json already declared without a licence file to back them. Two AGPL section 7 permissions: - group applications may be under any licence when they use the interface only through a named surface (static/licenses/APPLICATION-EXCEPTION.txt); the reference application is 0BSD so that copying it brings no AGPL code; - the Android application may be conveyed linked with Google Play services. Third-party code is accounted for: THIRD-PARTY-NOTICES.txt is generated from what a build ships (packaging/third_party_notices.py) for the deb/rpm venv and the frozen Windows node — PyAV's wheel grafts in libx264 and libx265, which its BSD licence does not mention — and the vendored browser libraries get their licence texts and htm-preact.js its provenance. Wheels carry SPDX metadata, RPMs %license, debs a DEP-5 copyright file, every Windows target LICENSE.txt. test_licensing.py holds the line: the LGPL layer imports nothing under the AGPL, the reference application nothing outside the application interface, and every SPDX line is one of the known ones. Co-Authored-By: Claude Opus 5.5

refactor: remove the unused GroupIndex.serialize chain

2026-09-28T14:24:12Z

serialize/deserialize had no production caller, and took with them the per-chunk signature, the ChaCha20 cipher variant and the zstandard dependency. Key derivations are unchanged. Docs corrected, including design §4.3's claim that chunks are compressed. Co-Authored-By: Claude Opus 5.5

docs: the Windows node's three modes and one lifecycle, and what it cost

2026-09-27T20:21:42Z

- MESHBAY_DESIGN.md §11.2: the node runs only while the app is open, at sign-in, or as a boot-time service; starting and stopping have one implementation, the CLI's; a second instance refuses before it writes anything the running one depends on. - packaging/win/README.md: the three modes, switching between them, upgrading a running node, where the log is, the service task's settings. - docs/windows-build.md: the build's smoke start of the frozen daemon, the log location, and what an upgrade does to a running node. - CLAUDE.md: four engineering lessons -- an upgrade that cannot stop the node installs around it; on Windows the CLI is the process it is stopping; a second instance must fail before it touches anything shared; a test that redirects HOME isolates nothing on Windows. Co-Authored-By: Claude Opus 5.5