@blamejs/core 0.18.37 → 0.18.38

package/CHANGELOG.md

@@ -8,6 +8,40 @@ upgrading across more than a few patches at a time.
 
 ## v0.18.x
 
+- v0.18.38 (2026-08-19) — **`COPY ... TO STDIN` was reported as a server-side file access whenever it carried more than one space.** `b.guardSql`'s `copy-file` detector finds a `COPY` that reads or writes a file on the database server, and excludes the client-streaming `STDIN` and `STDOUT` forms because those touch no file. The exclusion was a negative lookahead, and it only worked when the whitespace before the keyword was exactly one character: `COPY t TO STDIN` was quiet, `COPY t TO  STDIN` was reported critical.
+
+The exclusion is now decided by reading the following word rather than by a lookahead, so the spacing no longer changes the verdict.
+
+No API changes. Upgrade if you pass SQL fragments through `b.guardSql`. **Changed:** *The content-safety gate now refuses a pattern built at runtime* — `blamejs/no-regex-in-content-safety` reported pattern literals only, so `new RegExp(source)` passed it unnoticed anywhere under `lib/**/safe-*.js` or `lib/**/guard-*.js`. It now reports `new RegExp(...)` and `RegExp(...)`, in both the bare and member spellings — `globalThis.RegExp(src)` puts a MemberExpression in the callee and an identifier-only check permits it silently.
+
+Three call sites carry a suppression with its reason recorded beside it. Two of them never match anything against input: `b.guardRegex` asks the parser whether an operator-supplied pattern compiles at all and discards the result, and `b.safeJson` compiles a schema `pattern` precisely so `assertSafe` can screen the compiled form. The third is `b.guardSql`'s detector table, described below. · *The SQL detectors stay on the platform engine, and the reason is now recorded* — These 32 detectors are built with `new RegExp` and run against a caller's SQL, which reads like something the content-safety rule should forbid. Moving them to `b.regexLinear` — whose cost is the length of the subject whatever the pattern says — was tried and measured, and it is worse:
+
+| subject | linear | platform |
+| --- | --- | --- |
+| 158-byte benign SELECT | 1.4 ms | 0.001 ms |
+| 4 KiB benign SELECT | 15.4 ms | 0.012 ms |
+
+The engine expands each `{0,4000}` span into thousands of states, so every ordinary fragment pays. The platform engine's worst case over these same patterns, on adversarial input built to defeat every lazy span, is 5 ms at 32 KiB — less than the linear engine charges for a benign 4 KiB one. The swap would have made every request cost more than the attack it was meant to prevent.
+
+What bounds these patterns is the patterns: every span is explicitly capped and none pairs two quantifiers over an overlapping alphabet. That is a property of this table rather than a general licence, and it is written where the table is defined so a new detector gets the same check.
+
+SECURITY.md is corrected to match. It named a build gate retired in 0.18.37, said no primitive in the family "contains a regular expression" where the enforced claim is that none SCREENS with one, and now states plainly that a runtime-built pattern is not yet reported by the gate. **Fixed:** *The COPY file-access detector no longer depends on how much whitespace precedes STDIN* — The pattern excluded the safe forms with `\s+(?!STDIN\b|STDOUT\b)`. `\s+` is greedy but backtracks: given two spaces it could give one back, leaving ` STDIN` in front of the lookahead, which then read as "not STDIN" and reported a statement that opens no file.
+
+```
+COPY t TO STDIN     quiet
+COPY t TO  STDIN    reported as "reads or writes a server-side file"
+COPY t TO   STDIN   reported
+COPY t TO \n STDIN  reported
+```
+
+The exclusion is now tested BEFORE the whitespace is consumed — `\b(?:TO|FROM)\b(?!\s+(?:STDIN|STDOUT)\b)\s+` — so it is evaluated once, at a fixed position, and cannot interact with that quantifier at all.
+
+The obvious repair is worse. Teaching the lookahead to skip whitespace where it stood, `\s+(?!\s*(?:STDIN|STDOUT)\b)`, gives the two quantifiers the same alphabet: every backtrack re-scans the remainder of the run, which measures 45 ms on a 16,000-space run and grows quadratically — a denial of service introduced into the primitive whose job is to prevent one. Moving the test in front of `\s+` measures flat, and a cost regression check now covers it.
+
+What the detector catches is unchanged, and the lookahead is kept rather than replaced with a scan for a specific reason: its backtracking is what finds the file in `COPY (SELECT x FROM STDOUT) TO '/tmp/x'`, where the first candidate is excluded and the one that matters appears later in the same statement. A scan that resumed past the excluded match would miss it, because every match has to begin at `COPY`. `COPY t TO '/etc/passwd'` fires, `COPY t TO STDINX` fires because the word does not end at `STDIN`, and `COPY t TO STDOUT; COPY u TO '/tmp/x'` fires on the second statement.
+
+Twenty regression checks cover the whitespace forms, the nested case and the boundary. **References:** [PostgreSQL COPY — TO/FROM STDIN and STDOUT stream to the client](https://www.postgresql.org/docs/current/sql-copy.html)
+
 - v0.18.37 (2026-08-19) — **The no-regex rule for content-safety primitives never covered lib/parsers, where 55 patterns were screening adversarial input.** SECURITY.md states that no `b.guard*` or `b.safe*` primitive contains a regular expression, so a screen costs the length of its input and the byte cap that bounds the input bounds the screen. The build gate enforcing that selected files with `lib/(safe-|guard-)[^/]+\.js` — top level only. Every nested primitive was therefore outside it, and all five of them are the ones that parse untrusted bytes: `b.parsers.yaml`, `b.parsers.toml`, `b.parsers.ini`, `b.parsers.env` and `b.parsers.xml`. Between them they carried 55 pattern literals.
 
 All 55 are gone, and the gate now covers nested paths. Nothing about the parsers' behaviour changes: each screen was differential-tested against the pattern it replaced before the call site was swapped.

package/lib/guard-regex.js

@@ -2321,6 +2321,12 @@ function _ambiguityFindings(src, flags) {
     // at all" and returned every finding false, so a quadratic pattern using
     // any of that syntax walked straight past this gate.
     var compiles = true;
+    // The result is discarded and the pattern is never run against a subject —
+    // this asks the parser whether `text` is a regular expression at all, which
+    // is the opposite direction from screening input with one. Nothing a caller
+    // supplies is matched here; a source that does not compile simply reports as
+    // not-a-regex.
+    // eslint-disable-next-line blamejs/no-regex-in-content-safety
     try { RegExp(text, typeof flags === "string" ? flags : ""); }
     catch (_e) { compiles = false; }
     if (compiles) {

package/lib/guard-sql.js

@@ -248,11 +248,32 @@ var MASK_SPACE = " ";
 
 function _re(source) {
   // Construct each detector regex from an ASCII source string so the
-  // source file embeds no attack-character literals. Case-insensitive;
-  // detectors are intentionally global-free (first match is enough).
-  return new RegExp(source, "i");                                       // allow:dynamic-regex — detector source is a compile-time ASCII literal table below
+  // source file embeds no attack-character literals. Case-insensitive, and
+  // deliberately NOT global: `.test()` on a `g` regex advances `lastIndex` and
+  // answers differently on the next call with the same input.
+  //
+  // These stay on the platform engine, and that was measured rather than
+  // assumed. Compiling all 32 on b.regexLinear — whose cost is the length of the
+  // subject whatever the pattern says — makes a BENIGN 4 KiB fragment cost 15 ms
+  // against 0.012 ms here, because the NFA expands each `{0,4000}` span into
+  // thousands of states. The platform engine's own worst case over these
+  // patterns is 5 ms at 32 KiB of adversarial SQL, so the swap would have made
+  // every request pay more than the attack it was meant to prevent.
+  //
+  // What bounds these is the patterns themselves: every span is explicitly
+  // capped, and none pairs two quantifiers over an overlapping alphabet. That is
+  // a property of THIS table, not a general licence — a new detector needs the
+  // same check before it is added.
+  //
+  // The suppression below is the ONE audited exception in the family, and it is
+  // recorded rather than assumed: the alternative was measured and is worse, the
+  // sources are a fixed compile-time table rather than anything a caller
+  // supplies, and the cost is covered by a regression check in guard-sql.test.js.
+  // eslint-disable-next-line blamejs/no-regex-in-content-safety
+  return new RegExp(source, "i");                                               // allow:dynamic-regex — compile-time ASCII literal table, every span bounded
 }
 
+
 // \b word-boundary + optional whitespace/paren tolerance baked into
 // each source string. `[\s]` spans the comment-collapsed single spaces.
 var DETECTORS = [
@@ -263,7 +284,31 @@ var DETECTORS = [
     reason: "COPY ... PROGRAM executes a shell command (Postgres RCE)" },
   { code: "sql.file-access", severity: "critical", kind: "copy-file",
     family: "floor", dialect: "postgres",
-    re: _re("\\bCOPY\\b[\\s\\S]{0,4000}?\\b(?:TO|FROM)\\b\\s+(?!STDIN\\b|STDOUT\\b)"),
+    // STDIN / STDOUT stream to the client and touch no server-side file, so
+    // they are excluded — and the exclusion is tested BEFORE the whitespace is
+    // consumed, which is the whole trick here.
+    //
+    // Written the other way round, after `\s+`, it is wrong: `\s+` is greedy but
+    // backtracks, so given two spaces it gives one back, leaves " STDIN" in
+    // front of a lookahead that only knows how to reject "STDIN", and reports a
+    // client-side `COPY t TO  STDIN` as a server-side file access. One space was
+    // quiet and two were critical.
+    //
+    // Teaching that lookahead to skip whitespace (`(?!\s*(?:STDIN|STDOUT)\b)`)
+    // fixes the verdict and introduces a worse problem: `\s+` and the `\s*`
+    // range over the same characters, so every backtrack re-scans the rest of
+    // the run — 45 ms on a 16k-space run, quadratic, in the one primitive whose
+    // job is to not be a denial of service.
+    //
+    // In front of `\s+` the lookahead is evaluated once, at a fixed position,
+    // and cannot interact with that quantifier at all. Measured flat.
+    //
+    // A lookahead rather than a scan-and-compare because its backtracking is
+    // what finds the file in `COPY (SELECT x FROM STDOUT) TO '/tmp/x'`: the
+    // first candidate is excluded and the one that matters comes later in the
+    // SAME statement, which a scan resuming past the excluded match would miss,
+    // since every match has to begin at COPY.
+    re: _re("\\bCOPY\\b[\\s\\S]{0,4000}?\\b(?:TO|FROM)\\b(?!\\s+(?:STDIN|STDOUT)\\b)\\s+"),
     reason: "COPY TO/FROM <file> reads or writes a server-side file" },
   { code: "sql.file-access", severity: "critical", kind: "large-object",
     family: "floor", dialect: "postgres",

package/lib/safe-json.js

@@ -837,6 +837,12 @@ function _patternMatcher(pattern) {
       // branch twice. That is the overlap the alternation rule exists to
       // catch, so `/^(?=(a|A)+$)a+$/i` would pass a source-only screen and
       // then run, under those flags, against a value from the wire.
+      // Compiled precisely so assertSafe can screen the COMPILED form, per the
+      // comment above: a source-only screen misreads `(a|A)+` under `i`. The
+      // pattern here is the operator's schema `pattern` keyword — the input
+      // being validated rather than the implementation of a screen — and it is
+      // refused before it ever runs against a value.
+      // eslint-disable-next-line blamejs/no-regex-in-content-safety
       var native = new RegExp(source, flags);
       // assertSafe builds `new ErrorClass(code, message)`; SafeJsonError takes
       // them the other way round, so the screen reports through its own error.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/core",
-  "version": "0.18.37",
+  "version": "0.18.38",
   "description": "The Node framework that owns its stack.",
   "license": "Apache-2.0",
   "author": "blamejs contributors",

package/sbom.cdx.json

@@ -2,10 +2,10 @@
   "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
   "bomFormat": "CycloneDX",
   "specVersion": "1.5",
-  "serialNumber": "urn:uuid:446f4ad2-1001-404f-a62c-c116788ed0b8",
+  "serialNumber": "urn:uuid:3e525c66-4a72-4004-90a2-8985bbb5daa4",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-08-19T02:55:12.713Z",
+    "timestamp": "2026-08-19T06:46:25.351Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/core@0.18.37",
+      "bom-ref": "@blamejs/core@0.18.38",
       "type": "application",
       "name": "blamejs",
-      "version": "0.18.37",
+      "version": "0.18.38",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "The Node framework that owns its stack.",
-      "purl": "pkg:npm/%40blamejs/core@0.18.37",
+      "purl": "pkg:npm/%40blamejs/core@0.18.38",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/core@0.18.37",
+      "ref": "@blamejs/core@0.18.38",
       "dependsOn": []
     }
   ]