@ai-ecoverse/slicc-kernel 1.125.4 → 1.125.5

package/README.md

@@ -745,7 +745,7 @@ A `hostfs` mount is a folder exported by the local proxy ([slicc-node](https://g
 - **Grants:** `kernel.mount({ type: 'hostfs', source: 'project', target: '/mnt/project' })` asks the page's `hostfs(source, { readonly })` hook for a grant. The page holds the proxy key and asks the proxy (`POST /api/hostfs/grant`) for a token scoped to that one folder. The kernel sees only `{ url, token }`, never the proxy key, and the token never appears in mount options or `/proc/mounts`. When the proxy refuses a token, the kernel asks the hook once for a new one.
 - **Options:** `ro` mounts read-only, and `maxfile` caps file size as on any mount. There is no other size limit: reads and writes go in `maxIo` pieces (16 MiB unless the proxy says otherwise), so a file of any size the host can hold works. A proxy that advertises `ranges` in its grant (slicc-node 2.4, slicc-swift 1.4) makes the mount ranged, so programs read and write its files in pages and truncate through `setattr` `size`. With an older proxy files go whole, and a truncate on a ranged mount whose proxy was replaced by an older one is done by rewriting the file.
 - **Changes on the host** arrive as invalidations on a watch stream (`POST /api/hostfs/watch`), so an edit made outside shows up on the next access without a remount.
-- **Writes when the link drops:** after a mount's link drops, a write that returned success may not be on the host unless the program fsyncs or checks close, as on Linux with NFS: the shell ignores a redirection's close error ([#1062](https://github.com/ai-ecoverse/slicc-kernel/issues/1062)).
+- **Writes when the link drops:** after a mount's link drops, a write that returned success may not be on the host unless the program fsyncs or checks close, as on Linux with NFS: the shell ignores a redirection's close error ([#1062](https://github.com/ai-ecoverse/slicc-kernel/issues/1062)). How soon a write notices the loss is bounded: a folder that goes silent behind a live link fails the pending call after 20 s (see **Hanging folders** below), a port that dies fails it after 10 s without a ping answer, and a link that reports itself down (`ENOTCONN`) fails it at once. In every case the mount is then `nomedium` until it reconnects (see **Proxy loss** below), and until then each operation fails at once with `ENOMEDIUM`. A shell loop that keeps writing after a failed write (`for …; do echo …; done > file`) keeps running through its failing writes and exits non-zero at the end, as on Linux; stop at the first failed write (`echo … || exit 1`) to end at once ([#1077](https://github.com/ai-ecoverse/slicc-kernel/issues/1077)).
 - **Proxy loss:** when the watch stream ends, or is silent for 45 s, the kernel reconnects once at once. If that fails, the mount is `nomedium`, as with [removable media](#removable-media-fsa): operations fail with `ENOMEDIUM` (`ENODEV` for WASI), and the kernel keeps reconnecting with backoff (1 s to 30 s), so the folder comes back by itself when the proxy does. A mount made while the proxy is down starts as `nomedium`, and so does one whose grant or first watch takes more than 15 s; it comes up by itself when they arrive.
 - **Consistency:** a file that changes on the host while a program reads it fails with `ESTALE`, and the kernel restarts the whole read (up to 3 times) instead of stitching two versions together. On a ranged mount an open file keeps the version it was opened at (its ETag) until it writes, also when it is handed to a child process: a page fetched after the host changed the file fails the program's read with `ESTALE` ("Stale file handle") instead of mixing versions. A file deleted on the host while a program holds it open fails the next read that goes to the host with `ENOENT`, not with NFS's `ESTALE`.
 - **Over a port:** the hook may answer `{ port, token?, capabilities? }` instead, for a folder that doesn't come from slicc-node over HTTP: for example, a linked `slicc` CLI's export, which the page reaches over its own link. The page implements a `HostfsTransport` for the folder (`capabilities`, `token`, `maxIo`, `call(op, body)`, `read(fh, offset, size, ifMatch?)`, `write(fh, offset, bytes)`, `watch(signal, onEvent, onOpen)`, with slicc-node's ops and answers) and serves it with `serveHostfsPort(port, transport)`, exported from both entries, which returns a function that stops serving and closes the port.
@@ -1094,7 +1094,7 @@ Releases are cut by semantic-release on every push to `main`, in two jobs, and o
 
 Every change is certified in its pull request, before it merges (`cert-review-pr.yml`, next section), and `cert-review` is a required check of the merge queue, so every commit on `main`, and every release built from it, was certified first. A release is then **verified on npm** (`release / verify on npm` in `release.yml`, `tools/cert-review/verify.mjs`), in code, for every tag the run made:
 
-- It waits up to an hour for npm to serve the version (an accepted publish can take a while to appear), then downloads the tarball and checks `dist.integrity` (sha512), the SLSA v1 provenance (the tarball's sha512 is its subject; `release.yml` on `refs/heads/main`, a GitHub-hosted builder; `gitCommit` = `gitHead` = the tag, on `main`), and `npm audit signatures`. A version that `release-recover.mjs` skipped because npm's `latest` is newer (#837) has nothing to verify.
+- It waits up to an hour for npm to serve the version (an accepted publish can take a while to appear; 1.125.4 took 55 min). `release-recover` waits 25 min for a version it just published and then hands it to this job instead of failing, and a version npm still doesn't serve after the hour is a "not served yet, re-run" failure, never a supply-chain alert. It then downloads the tarball and checks `dist.integrity` (sha512), the SLSA v1 provenance (the tarball's sha512 is its subject; `release.yml` on `refs/heads/main`, a GitHub-hosted builder; `gitCommit` = `gitHead` = the tag, on `main`), and `npm audit signatures`. npm serves a version's attestations a little after the version itself, so a 404 from the attestations, or `npm audit signatures`' E404 on them, is retried within the same hour: it's a supply-chain alert only once the version has been served for 30 min, its packument has stopped changing for 10, and the attestations still answer 404, or the hour has run out. Any other status, or attestations that don't match, fail at once. A version that `release-recover.mjs` skipped because npm's `latest` is newer (#837) has nothing to verify.
 - It then writes `certified @ai-ecoverse/slicc-kernel@<v> sha256=<64 hex> (covers <first>–<v>; ci: <run>; pr-certified: <each merged pull request's cert-review at its merge>; known: <open known-issue issues>)` into the GitHub release's notes, between `<!-- cert-verify -->` markers. homescoop's ci reads exactly that prefix and re-hashes the npm tarball against it. `covers` starts after the last version npm serves, so a skipped version is covered by the next. Notes that already carry the identical line stay unchanged. A pull request's `cert-review` is the newest finished one (success, failure or error) on its head at or before its merge, or the newest pending one if none had finished. A re-review that a later `merge-ok` re-label starts on the same head, still pending at the merge or ending after it, doesn't change what the merge queue saw, and a status posted after the merge can't change a release's line.
 - A mismatch writes no line. The job is red with a `supply-chain alert`, and so is a line already in the notes with another sha256.
 

package/dist/kernel-worker.js

@@ -6632,7 +6632,7 @@ function satisfies(version, range2) {
 }
 
 // src/version.ts
-var KERNEL_VERSION = true ? "1.125.4" : "0.0.0-dev";
+var KERNEL_VERSION = true ? "1.125.5" : "0.0.0-dev";
 var OS_RELEASE = "6.0.0-slicc";
 function procVersion() {
   return `Linux version ${OS_RELEASE} (slicc-kernel ${KERNEL_VERSION}) #1 SMP PREEMPT_DYNAMIC

package/dist/node-process-worker.js

@@ -6325,7 +6325,7 @@ var KERNEL_VERSION, OS_RELEASE;
 var init_version = __esm({
   "src/version.ts"() {
     "use strict";
-    KERNEL_VERSION = true ? "1.125.4" : "0.0.0-dev";
+    KERNEL_VERSION = true ? "1.125.5" : "0.0.0-dev";
     OS_RELEASE = "6.0.0-slicc";
   }
 });

package/dist/node.js

@@ -7086,7 +7086,7 @@ function satisfies(version, range2) {
 }
 
 // src/version.ts
-var KERNEL_VERSION = true ? "1.125.4" : "0.0.0-dev";
+var KERNEL_VERSION = true ? "1.125.5" : "0.0.0-dev";
 var OS_RELEASE = "6.0.0-slicc";
 function procVersion() {
   return `Linux version ${OS_RELEASE} (slicc-kernel ${KERNEL_VERSION}) #1 SMP PREEMPT_DYNAMIC

package/dist/process-worker.js

@@ -2655,7 +2655,7 @@ var KERNEL_VERSION, OS_RELEASE;
 var init_version = __esm({
   "src/version.ts"() {
     "use strict";
-    KERNEL_VERSION = true ? "1.125.4" : "0.0.0-dev";
+    KERNEL_VERSION = true ? "1.125.5" : "0.0.0-dev";
     OS_RELEASE = "6.0.0-slicc";
   }
 });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ai-ecoverse/slicc-kernel",
-  "version": "1.125.4",
+  "version": "1.125.5",
   "description": "SLICC's wasm-realm kernel: run Emscripten programs in the browser against OPFS, with fork, spawn, pipes and waitpid",
   "type": "module",
   "license": "Apache-2.0",