@clear-capabilities/agentic-security-scanner 0.164.0 → 0.165.1

package/CHANGELOG.md

@@ -9,6 +9,20 @@
 > make the history less accurate, not more.
 
 
+## 0.165.1 - documentation: the project guide no longer says the execution suites skip on hosted Linux
+
+Documentation-only correction. The root `CLAUDE.md` still described Linux as `unverified` and said the execution suites skip on the hosted runner; since 0.165.0 they run in the `sandbox-linux` job (which fails on any skip) and Linux is recorded as `partially-verified`. The release leg itself still runs only the static closure, now stated with the real reason: the full closure has never been timed inside a hosted leg's budget. No code changed.
+
+## 0.165.0 - Linux process-count cap proved on a hosted runner; the execution suites run on Linux
+
+**The process-count cap works on Linux and is proved.** The cap was never applied before because the resource prelude ran under `dash`, which has no `ulimit -u`. The namespace backend now applies it with `prlimit --nproc` to the task's command only, after the confinement is built. On the hosted x86_64 `sandbox-linux` job, six concurrent children all start under a cap of 512 and only one starts under a cap of 3, in default mode and in capability mode. The probe is paired with fault injection: it fails against a runner that drops the cap and against one that caps everything. A requested cap is never silently dropped; a host without `prlimit` reports it unsupported. `process-cap` is verified for Linux only after that hosted result, and stays unverified on macOS.
+
+**The execution suites now run on Linux with Linux semantics, with no skips.** The capabilities, trust-boundary and attack-corpus suites assert ENOENT or EROFS evidence for out-of-root access instead of macOS-style denial, use heartbeats instead of host pids for liveness, and expect a declared network destination to block the task. No assertion was weakened. A skip in the trust-boundary suite is gone. The hosted `sandbox-linux` job now also runs the capabilities, verification, invariants, documentation, trust-boundary and evidence-issuer suites and fails on any skip: 737 tests ran and passed, 0 skipped, 0 failed.
+
+**A responsiveness defect found by the hosted run.** The supervisor's periodic synchronous `ps` sweep kept the controller's event loop 58 to 62 percent busy on Linux. It is off for the namespace backend, where the kernel already kills the namespace with its supervisor.
+
+**Still open.** The hosted release leg still runs only the static closure: running the full closure there has never been timed on a hosted runner and would duplicate the test shards. Mediated network remains unsupported on Linux. The process-count behaviour was checked on kernel 6.8 only; older kernels count the limit per real uid system-wide, so a small cap could behave differently. The real-code accuracy gates and the routing promotion gate still need independently adjudicated data that code cannot produce, so the PRD closure verification still reports not complete.
+
 ## 0.164.0 - Linux isolation proved on a hosted runner, six controller limits enforced, closure evidence from CI
 
 Closing gaps from the Differentiation PRD that software can close. The gaps that remain are named at the end; none of them is hidden by this release.

package/dist/9560.index.js

@@ -373,8 +373,8 @@ const MANIFEST_REQUIRED = ['schema', 'schemaVersion', 'taskId', 'repository', 'p
 
 // Resource limits a manifest can carry. The first three come straight from the
 // assurance config (same ranges), the file-size cap is enforced by the sandbox
-// prelude, and the last two are CARRIED but never claimed enforced: see
-// `RESOURCE_ENFORCEMENT` in runner.js.
+// prelude, the process-count cap is enforced on the Linux namespace backend only (prlimit, proved by an
+// active probe), and the memory cap is CARRIED but never claimed enforced.
 const RESOURCE_RANGES = Object.freeze({
   timeoutMs: { min: config/* LIMITS */.b1.timeoutMs.min, max: config/* LIMITS */.b1.timeoutMs.max },
   maxOutputBytes: { min: config/* LIMITS */.b1.maxOutputBytes.min, max: config/* LIMITS */.b1.maxOutputBytes.max },
@@ -1532,11 +1532,11 @@ function platformStatements() {
       evidence: 'sandbox-linux CI job (hosted ubuntu-latest, x86_64); scripts/sandbox-linux-verify.mjs',
       verifiedControls: Object.freeze([
         'write-confinement', 'read-denial', 'env-scrub', 'network', 'tree-termination', 'file-size-limit',
-        'fs-read-confinement', 'fs-multi-root-write',
+        'fs-read-confinement', 'fs-multi-root-write', 'process-cap',
       ]),
       unsupportedControls: Object.freeze(['network-mediation']),
-      unassertedControls: Object.freeze(['process-cap']),
-      note: 'advertised for enforced mode. Proved by active probes on the hosted Linux runner (not on every Linux host): write-confinement, read-denial, env-scrub, network, tree-termination, file-size-limit, fs-read-confinement, fs-multi-root-write. Mediated network is NOT implemented on the namespace backend (an empty network namespace has no path to a proxy), so a task that declares a network destination is blocked on Linux, never allowed. Process-count caps are never claimed: the cause of the earlier non-refusal was found (the shell used for the resource prelude has no process-limit option, so the cap was never applied) and no replacement has been proved. The attack corpus is not run in the sandbox-linux job, so corpus coverage stays unverified on Linux.',
+      unassertedControls: Object.freeze([]),
+      note: 'advertised for enforced mode. Proved by active probes on the hosted Linux runner (not on every Linux host): write-confinement, read-denial, env-scrub, network, tree-termination, file-size-limit, fs-read-confinement, fs-multi-root-write, process-cap (a per-user-namespace process-count cap applied with prlimit after the confinement is built; the shell ulimit it replaces does not exist in dash). Mediated network is NOT implemented on the namespace backend (an empty network namespace has no path to a proxy), so a task that declares a network destination is blocked on Linux, never allowed. Process-count caps are claimed on Linux only, and only as that probe shows them; memory caps are not enforced. The attack corpus is not run in the sandbox-linux job, so corpus coverage stays unverified on Linux.',
     },
     darwin: {
       backend: 'userspace', status: 'host-proved-not-advertised',