@ai-ecoverse/slicc 1.44.5 → 1.44.6

package/README.md

@@ -415,7 +415,7 @@ Lists running CDP endpoints and installed browsers, best match first. The browse
 **Running endpoints** come from four places:
 - `DevToolsActivePort` files in the default user-data dirs of the browsers below, in each SLICC profile under the profiles dir (see `slicc launch`), in SLICC six's profiles (see [Using SLICC six's Chrome profile](#using-slicc-sixs-chrome-profile)), and on Linux in the flatpak (`~/.var/app/<id>/config/…`) and snap (`~/snap/chromium/common/chromium`) dirs. The file's port must answer `/json/version` with the websocket path on the file's second line, otherwise the file is stale and ignored. A file without a second line starting with `/` is ignored too.
 - `GET /json/version` on `127.0.0.1:9222` to `9229`.
-- The process list (`ps -ax -o pid= -o command=`; on Windows `Get-CimInstance Win32_Process` with `ProcessId` and `CommandLine`, as JSON): each process started with `--remote-debugging-port=<n>` or `--remote-debugging-port <n>`. Pid 0, `slicc` itself, and commands run by a wrapper (`node`, `npx`, `tsx`, `npm`, `open`, `bash`, `zsh`, `sh`, `csh`, `fish`, `dash`, `timeout`, `env`, `sudo`, `caffeinate`, `cmd`, `powershell`, `pwsh`) are skipped. Port 0 means the port is in the `DevToolsActivePort` of the process's `--user-data-dir` (its value runs to the next whitespace followed by `--` or to the end, so paths with spaces work, and a quoted value runs to the matching quote), checked as above; without one, or with one under a `slicc/profiles` folder that isn't one of six's profiles, the process is skipped. Any other port is asked for `/json/version` on `127.0.0.1`. The exact rules are in [slicc-browsers](https://github.com/ai-ecoverse/slicc-browsers#the-process-source).
+- The process list (`ps -ax -o pid= -o command=`; on Linux, when that command fails (missing, or a BusyBox `ps` without `-ax`), `/proc/<pid>/cmdline` of every numeric pid, its NUL-separated arguments joined by spaces; on Windows `Get-CimInstance Win32_Process` with `ProcessId` and `CommandLine`, as JSON): each process started with `--remote-debugging-port=<n>` or `--remote-debugging-port <n>`. Pid 0, `slicc` itself, and commands run by a wrapper (`node`, `npx`, `tsx`, `npm`, `open`, `bash`, `zsh`, `sh`, `csh`, `fish`, `dash`, `timeout`, `env`, `sudo`, `caffeinate`, `cmd`, `powershell`, `pwsh`) are skipped. Port 0 means the port is in the `DevToolsActivePort` of the process's `--user-data-dir` (its value runs to the next whitespace followed by `--` or to the end, so paths with spaces work, and a quoted value runs to the matching quote), checked as above; without one, or with one under a `slicc/profiles` folder that isn't one of six's profiles, the process is skipped. Any other port is asked for `/json/version` on `127.0.0.1`. The exact rules are in [slicc-browsers](https://github.com/ai-ecoverse/slicc-browsers#the-process-source).
 - Each `--cdp` URL: `http(s)://host:port`, `ws(s)://host:port/devtools/browser/<id>`, `host:port` or a bare port. One that doesn't answer is reported on stderr and left out; the exit status stays 0.
 
 Endpoints are merged by host and port. A `DevToolsActivePort` file wins over `--cdp`, which wins over the process list, which wins over the port probe. For each endpoint, `/json/version` gives the name, version and `webSocketDebuggerUrl`, and `/json/list` gives the seven tabs: `page` targets whose origin is `https://<label>.sliccy.ai`, other than `www` (`:443` is the same origin, any other port isn't). An endpoint's `cdp` has its host in lower case, with `localhost` and `::1` written as `127.0.0.1`. A `DevToolsActivePort` whose port is open but serves no `/json/version` (Chrome's opt-in remote debugging of a running browser) is listed as `wsOnly`, with the websocket URL from the file and no tab check.
@@ -1013,7 +1013,7 @@ A node checks every address it connects to for the link's `tcp`, `http`, `ws` an
 **Local default** (the bridge to the browser `slicc` controls). The remote default, with loopback and the private ranges (`127.0.0.0/8`, `::1/128`, `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `fc00::/7`) allowed instead of denied, so this machine and the LAN are reachable. `--deny 127.0.0.0/8` and `--deny 192.168.0.0/16` take loopback and the LAN back out.
 
 **Protected ports**, in both defaults and in every mode (`slicc`, `attach`, `open`, `pair`, `--default-browser` and `follow`). Two kinds:
-- **Debugging ports:** ports 9222–9229; every port in a `DevToolsActivePort` file that browser discovery would read (default user-data dirs, SLICC profiles and six's profiles); the port of every running process started with `--remote-debugging-port=<n>` (from the process list, as discovery reads it: wrappers skipped, and for port 0 the `DevToolsActivePort` of its `--user-data-dir`); and the debugging port of every browser the node was given or launched (`slicc`'s browsers, `attach --cdp` and `--cdp-extra`, `follow --cdp`). Nothing is probed: files and the process list are only read. They are read at startup, again whenever a `tcp`, `http`, `ws` or `ssh` connection goes to an address of this machine on a port not yet denied (the files each time, the process list at most once a second), and every 5 s, so a browser that starts later is denied before its first connection. No `--allow` reopens one, not even `--allow 127.0.0.1:9222` or `--allow 127.0.0.0/8`: a debugging port wins over every other rule. Only `--expose-debug-port <port>` (repeatable, every mode) leaves one open, and only a port that is a debugging port when the node starts; any other port, or the port of a browser the node was given or launched, is an error (exit 1), since `cdp` is the way to those browsers. So seven never reaches raw CDP on this machine, `<host>.slicc.internal:9222` included, unless the user named that port.
+- **Debugging ports:** ports 9222–9229; every port in a `DevToolsActivePort` file that browser discovery would read (default user-data dirs, SLICC profiles and six's profiles); the port of every running process started with `--remote-debugging-port=<n>` (from the process list, as discovery reads it: wrappers skipped, and for port 0 the `DevToolsActivePort` of its `--user-data-dir`); and the debugging port of every browser the node was given or launched (`slicc`'s browsers, `attach --cdp` and `--cdp-extra`, `follow --cdp`). Nothing is probed: files and the process list are only read. The files are read at startup, every 5 s, and again whenever a `tcp`, `http`, `ws` or `ssh` connection goes to an address of this machine on a port not yet denied. The process list is read at startup, then in the background, one scan at a time: about every second while such connections keep coming (until 30 s pass without one; between two scans it pauses at least as long as the last one took), and every 30 s while idle. A connection uses the list only if its scan started less than about 1 s earlier. With an older list (the first connection after a quiet spell, say) it waits for a scan that started after it came, bounded by the scan's timeout (5 s, plus the rest of a scan already running), and if that scan fails or times out the connection is refused (`EACCES`, reason `a browser debugging port: couldn't list running browsers`). If no process list can be read at startup (no working `ps`, and on Linux no readable `/proc`), the node says so once on stderr: `slicc: can't list running browsers here (<why>); connects to this machine's own addresses are refused`. Such a host is fail-closed by design: every connection to its own addresses is refused until a scan works. A scan that fails later is reported once (`couldn't list running browsers for their debugging ports`), and again when scanning works again; the last good list is kept, but an old list never lets a connection through by itself. Connections to other hosts never wait. So a browser that starts later is denied before its first connection, once it has been running for about a second. No `--allow` reopens one, not even `--allow 127.0.0.1:9222` or `--allow 127.0.0.0/8`: a debugging port wins over every other rule. Only `--expose-debug-port <port>` (repeatable, every mode) leaves one open, and only a port that is a debugging port when the node starts; any other port, or the port of a browser the node was given or launched, is an error (exit 1), since `cdp` is the way to those browsers. So seven never reaches raw CDP on this machine, `<host>.slicc.internal:9222` included, unless the user named that port.
 - **The node's own listeners** (the kernel listener and, for `open` and `pair`, the loopback listener): denied the same way, but an `--allow` for exactly the same address and port reopens one.
 
 Both are denied:
@@ -1992,7 +1992,7 @@ The remote default, but it **also allows loopback and the private ranges** (`10/
 
 Both defaults, in every mode (local and remote), deny this machine's browser debugging ports on `127.0.0.0/8`, `::1` and **every address of this machine**, so `<host>.slicc.internal:<port>` (which the page sends as `127.0.0.1`) is refused too:
 - **Which:** `9222`–`9229`; every port in a `DevToolsActivePort` file the node finds read-only; the port of every running process started with `--remote-debugging-port` (for port 0, the `DevToolsActivePort` of its `--user-data-dir`); and the debugging port of each browser the node was given or launched.
-- **When:** at startup, every 5 s, and on each `tcp` connect (`net`, `http`, `ws`, `ssh` forwarding) to an address of this machine on a port not yet denied: the files are read again then, and the process list when it is more than 1 s old. So a browser that starts later is refused before its first connection.
+- **When:** the files at startup, every 5 s, and on each `tcp` connect (`net`, `http`, `ws`, `ssh` forwarding) to an address of this machine on a port not yet denied. The process list at startup, then in the background (one scan at a time): about every 1 s while such connects keep coming (until 30 s without one; a slow scan is followed by a pause as long), every 30 s while idle. A connect uses the list only if it is under about 1 s old; otherwise it waits for a fresh scan, bounded by the scan's timeout, and is refused if that scan fails or times out (reason `a browser debugging port: couldn't list running browsers`). Connects to other hosts never wait. On Linux the list falls back to `/proc` when `ps` fails. With no list at all at startup, the node says `can't list running browsers here (…); connects to this machine's own addresses are refused` once on stderr; a later failed scan is reported once, and again when it recovers. So a browser that starts later is refused before its first connection, once it has run for about a second.
 - **Above every rule:** no `--allow` reopens one, `--allow 127.0.0.1:9222` included. A refusal is `EACCES`, reason `a browser debugging port`.
 - **Opt-in:** only `--expose-debug-port <port>` (repeatable) leaves a port of the first three kinds open, and only one that is a debugging port at startup. Any other port is an error, and so is a browser the node was given or launched: `cdp` is the way to them.
 - **HELLO:** `policy.deny` lists the loopback denies of the ports known at startup; `policy.summary` ends in `exposes debugging ports <ports>`, the ports actually exposed.
@@ -2026,7 +2026,7 @@ Front ends and capabilities follow a node's links with `node.Node.Subscribe(func
 
 In the same process, probe ports, dirs and a process list passed in explicitly (`Options.ProbePorts`, `Options.Home`, `Options.ProfilesDir`, and `Options.Processes`, which returns the output of the process-list command) are still used. `Options.Transport` and `Options.Dial` replace discovery's HTTP transport and TCP dial; the corpus test fakes every server with them, and its process list is fake too. `test/integration`'s `TestMain` sets `SLICC_DISCOVERY=isolated` and unsets `SLICC_USER_DATA_DIR`, and points `HOME`, `APPDATA` and the XDG dirs, `XDG_STATE_HOME` included (and `LOCALAPPDATA`, and `USERPROFILE` except on Windows, where a Chrome started with a temporary one never writes `DevToolsActivePort`; the tests that have `slicc` launch a real Chrome give it the real `LOCALAPPDATA` on Windows, which they only do on CI) at a temporary directory for itself and every `slicc` it starts, so no test can reach the browsers of the machine it runs on. It also puts a stand-in `jerk` first on `PATH` that fails `--version` (on Windows one for every `PATHEXT` extension), so slicc never finds the machine's own slicc-jerk there, while every other tool keeps its own path. The tests that want a jerk put the fake jerk's dir before it. Tests opt in to more with a fake home or fake endpoints. The Chrome the harness starts itself gets the real environment.
 
-**Debugging ports in tests: `SLICC_PROTECTED_PORTS`** (test-only). `<first>-<last>` (or one port) adds to 9222–9229 the range every mode denies (see [Network policy](#network-policy)); 9222–9229 stay denied. The debugging-port tests (`test/integration/debugports_test.go`) set it to two free ports where fakes listen, write fake `DevToolsActivePort` files for two more under `SLICC_DISCOVERY=home`, give a fake CDP endpoint as `--cdp-extra` or `--cdp`, and after link-up write another `DevToolsActivePort` file and start two fake browsers with `--remote-debugging-port` (one with a port, one with 0 and a `--user-data-dir`). They prove, in every mode, that a link `net` or `http` request to each of them is refused, an exact `--allow` included, that a browser that starts later is refused at once, and that `--expose-debug-port` opens only what it names, without ever touching 9222–9229 on the machine they run on.
+**Debugging ports in tests: `SLICC_PROTECTED_PORTS`** (test-only). `<first>-<last>` (or one port) adds to 9222–9229 the range every mode denies (see [Network policy](#network-policy)); 9222–9229 stay denied. The debugging-port tests (`test/integration/debugports_test.go`) set it to two free ports where fakes listen, write fake `DevToolsActivePort` files for two more under `SLICC_DISCOVERY=home`, give a fake CDP endpoint as `--cdp-extra` or `--cdp`, and after link-up write another `DevToolsActivePort` file and start two fake browsers with `--remote-debugging-port` (one with a port, one with 0 and a `--user-data-dir`). They prove, in every mode, that a link `net` or `http` request to each of them is refused, an exact `--allow` included, that a browser that starts later is refused on the first connection after more than 1 s without one, and that `--expose-debug-port` opens only what it names, without ever touching 9222–9229 on the machine they run on. Tests of `browser.Guard` with a fake process table prove that a connect to this machine with a stale list waits for a gated, slow scan and is decided by it while connects to other hosts don't wait, that the list is rescanned about every second after a connect and connects then don't wait, that a scan that fails or times out refuses the connect, that failure and recovery are each reported once, that an idle node scans at most twice in 5 s, and that shutdown reports no failure; every connect in them has a deadline. **`SLICC_PROC_ROOT`** (test-only) replaces `/proc` for the Linux fallback. With a failing `ps` first on `PATH`, the tests prove that `slicc attach` reads a fake `/proc` on Linux (its browser's port refused, a browser added later refused on its first connection, other loopback ports open, no failure line) and that with no `/proc` either it prints the startup line once and refuses connects to this machine.
 
 **SLICC six's profile in tests.** The `--profile six` tests build fake six profile trees in a fake home only: each OS's layout, a mixed-case name, a symlinked profile and root, `SingletonLock` (or `lockfile`) live, stale and absent, and debuggable endpoints that are fakes or the harness's own headless Chrome on a free port. They check the trees byte for byte after a launch, an attach and an exit. A fake browser (`testdata/fakechrome`) stands in for Chrome where a real one would write to the profile itself. The one real-Chrome launch into a fake six profile checks that nothing was seeded; on Windows it puts that profile at `SLICC_USER_DATA_DIR` in a temporary dir, since that Chrome keeps the real `LOCALAPPDATA` (see below).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ai-ecoverse/slicc",
-  "version": "1.44.5",
+  "version": "1.44.6",
   "description": "SLICC's command line for seven: links a machine's network, compute and browsers to seven over WebRTC",
   "license": "Apache-2.0",
   "repository": {
@@ -18,12 +18,12 @@
     "node": ">=18"
   },
   "optionalDependencies": {
-    "@ai-ecoverse/slicc-darwin-arm64": "1.44.5",
-    "@ai-ecoverse/slicc-darwin-amd64": "1.44.5",
-    "@ai-ecoverse/slicc-linux-arm64": "1.44.5",
-    "@ai-ecoverse/slicc-linux-amd64": "1.44.5",
-    "@ai-ecoverse/slicc-windows-arm64": "1.44.5",
-    "@ai-ecoverse/slicc-windows-amd64": "1.44.5",
+    "@ai-ecoverse/slicc-darwin-arm64": "1.44.6",
+    "@ai-ecoverse/slicc-darwin-amd64": "1.44.6",
+    "@ai-ecoverse/slicc-linux-arm64": "1.44.6",
+    "@ai-ecoverse/slicc-linux-amd64": "1.44.6",
+    "@ai-ecoverse/slicc-windows-arm64": "1.44.6",
+    "@ai-ecoverse/slicc-windows-amd64": "1.44.6",
     "@ai-ecoverse/slicc-jerk": "^1.0.0"
   }
 }