@blamejs/core 0.16.30 → 0.16.31

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.16.x
 
+- v0.16.31 (2026-07-13) — **Vendored library bundles ship as unminified, reviewable source at the same pinned versions, removing the last dynamic-code-execution shims from the package.** The five vendored library bundles -- @noble/ciphers 2.2.0, @noble/curves 2.2.0, @noble/post-quantum 0.6.1, @simplewebauthn/server 13.3.2, and the @peculiar/x509 2.0.0 + pkijs 3.4.0 PKI meta-bundle -- now ship as unminified esbuild output of the same pinned upstream versions, so an operator can open any lib/vendor/*.cjs and read it, or diff it against upstream at the MANIFEST-pinned version, instead of auditing multi-hundred-KB minified lines. Their reflect-metadata dependency now resolves to upstream's lite build, which drops the legacy global-object probes (Function("return this") and indirect eval) that could never execute on supported Node versions -- the published package now contains no eval or Function-constructor construct outside the documented worker-thread sandbox compiler. The vendor pipeline records the exact build invocation in MANIFEST.json, can rebuild the PKI meta-bundle at pinned component versions, and a codebase-patterns gate refuses any future refresh that reintroduces minified or dynamic-execution output under lib/vendor/. The repository supply-chain policy adds audited dispositions for shell, filesystem, and debug access, re-enables the eval alert class now that the package contains none, and narrows the minified-code disposition to the signed data payload carriers -- the code bundles themselves are enforced unminified by an in-repo gate. **Changed:** *Vendored bundles are unminified, reviewable esbuild output at the same pinned upstream versions* — lib/vendor/noble-ciphers.cjs, noble-curves.cjs, noble-post-quantum.cjs, simplewebauthn-server.cjs, and pki.cjs are rebuilt without minification from the same pinned upstream versions recorded in lib/vendor/MANIFEST.json (@noble/ciphers 2.2.0, @noble/curves 2.2.0, @noble/post-quantum 0.6.1, @simplewebauthn/server 13.3.2, @peculiar/x509 2.0.0 + pkijs 3.4.0). Exports, versions, and runtime behavior are unchanged; upstream license headers and esbuild's bundled-license footers are preserved. The five bundles grow from roughly 1.2 MB to 2.7 MB on disk (the npm tarball transfers compressed), in exchange for source an operator or scanner can actually review and diff against upstream. · *reflect-metadata inside the WebAuthn and PKI bundles resolves to upstream's lite build, removing Function("return this") and indirect-eval global probes* — The @simplewebauthn/server and PKI meta-bundles pull in reflect-metadata (decorator metadata for their ASN.1 schema serializers). The bundles now resolve it to the package's own ./lite entry at the same pinned version: an identical metadata API with the same cross-copy registry protocol, built for runtimes with native globalThis -- it contains none of the legacy global-object probes (Function("return this") / indirect eval) that were unreachable dead code on the framework's Node floor anyway. With this change the published package contains no eval, indirect eval, or Function-constructor construct outside b.sandbox's worker-thread compiler, which is the documented isolation boundary for operator-submitted code. · *Vendor pipeline: pinned PKI meta-bundle rebuilds, and the manifest bundler field derives from the actual build invocation* — scripts/vendor-update.sh now accepts the PKI meta-bundle's manifest version form directly (for example: vendor-update.sh peculiar-pki "2.0.0+pkijs-3.4.0") and installs exactly those @peculiar/x509 and pkijs component versions, where previously it could only bundle latest. The bundler field in lib/vendor/MANIFEST.json is now written by the script from the esbuild invocation that actually produced the artifact, so the recorded build command can no longer drift from the real one. · *Package-scanner policy adds shell, filesystem, and debug access dispositions and re-enables the eval alert class* — socket.yml documents why shell access (all process execution goes through b.processSpawn -- fixed binary, argument array, never shell:true), filesystem access, and debug access (no debugger statements or node:inspector in first-party code; Reflect metadata in the vendored ASN.1 serializers is reflection, not code execution) are inherent to a server framework. The eval alert class is deliberately no longer suppressed: the package contains no eval or Function-constructor construct outside the documented sandbox worker, so a future occurrence is a genuine regression signal rather than recurring noise. The minified-code class stays dispositioned, narrowed to the signed data payload carriers (lib/vendor/*.data.js): minified-code detectors also fire on high-density embedded-asset files, which those carriers are by design -- a 76-char-wrapped base64 payload plus a multi-KB signature line, verified at every load. The unminified property of the code bundles is enforced by the repository's own gate, not by the scanner class. **Detectors:** *Vendored bundles must stay unminified and free of dynamic-code-execution constructs* — A codebase-patterns gate walks every JS artifact under lib/vendor/ and refuses minified bundle output (whole-file average line length, with wide margins around the measured unminified and minified populations) and any eval, indirect-eval, Function-constructor, createRequire, or process.binding token. A vendor refresh that reintroduces --minify or an upstream global-object eval probe fails the gate before it can ship. · *Scanner policy keeps the minified-code class dispositioned while signed data carriers ship* — A companion gate refuses removing socket.yml's minifiedFile disposition while lib/vendor/*.data.js payload carriers ship: minified-code detectors match the carriers' high-density base64-plus-signature shape, and an omitted issue rule falls back to dashboard defaults, so dropping the entry would re-report the known-benign artifacts on every routine scan.
+
 - v0.16.30 (2026-07-13) — **Reject a malformed IPv6 address whose '::' compresses no groups (and a leading-zero embedded-IPv4 tail) in the shared IP validator and the CIDR guard, and complete third-party license attribution for the vendored elliptic-curve library and the Public Suffix List.** The shared IPv6 text parser accepted an address where a '::' sat next to a full eight explicit groups (for example 1:2:3:4:5:6:7:8::, ::1:2:3:4:5:6:7:8, or 1:2:3:4:5:6:7::8). RFC 4291 §2.2 defines '::' as an abbreviation for one or more all-zero groups, so those forms compress nothing and are not valid IPv6 text -- Node's built-in net.isIP rejects every one of them. The parser computed the number of groups to insert but only rejected a negative count, so a zero-insert '::' passed. Because each accepted spelling still normalizes to the same address as its canonical form, no allow/deny decision was bypassed, but the validator disagreed with net.isIP and with any strict peer parser on a whole class of inputs. b.mail (SPF/DMARC/RBL/greylist/HELO) and b.guardCidr both parse IPv6 through the affected code, so both now reject these forms. The embedded IPv4 tail of an IPv4-mapped address is also now validated with the framework's strict dotted-quad check, so a leading-zero, octal-ambiguous octet such as ::ffff:01.2.3.4 is refused rather than silently reinterpreted. Separately, the third-party NOTICE file was missing two vendored components that ship in the package -- the @noble/curves elliptic-curve library (MIT, used by the OPRF primitive) and the Mozilla Public Suffix List (MPL-2.0) -- both are now attributed, and a repository supply-chain policy records why the framework's inherent network, configuration, vendored-bundle, and data-file characteristics are expected. **Changed:** *Complete third-party license attribution for the vendored @noble/curves library and the Public Suffix List, and refresh the vendored Public Suffix List* — The NOTICE file, which attributes every third-party component vendored under lib/vendor/, was missing two that ship in the package: the @noble/curves elliptic-curve library (MIT, used by the OPRF primitive) and the Mozilla Public Suffix List (MPL-2.0, used for organizational-domain derivation in DMARC alignment, BIMI scoping, and cookie-scope confinement). Both are now attributed; the Public Suffix List entry records that it is vendored verbatim under MPL-2.0 with its canonical source URL, satisfying MPL-2.0 §3.2. A stale vendored-library version in the same file was also corrected. The vendored Public Suffix List itself was refreshed to the current upstream snapshot so organizational-domain derivation reflects the latest registry delegations. A repository supply-chain policy also documents why the framework's inherent network egress, configuration reads, vendored minified bundles, and permissively- or open-data-licensed data files are expected characteristics rather than findings. **Security:** *b.mail and b.guardCidr reject a malformed IPv6 address whose '::' compresses zero groups, matching RFC 4291 and net.isIP* — The shared IPv6 text parser inserted 8 - (left groups) - (right groups) zero groups for a '::' and rejected only a negative result, so an address with a full eight explicit groups adjacent to a '::' -- 1:2:3:4:5:6:7:8::, ::1:2:3:4:5:6:7:8, 1:2:3:4:5:6:7::8, 1:2:3:4::5:6:7:8 -- was accepted even though RFC 4291 §2.2 requires '::' to stand for at least one all-zero group and net.isIP rejects all of them. The parser now requires a '::' to insert at least one group. Every affected spelling normalized to the same address as its canonical form, so no CIDR or SPF/DMARC allow/deny decision was bypassed; the fix removes a parser divergence from the platform and peer parsers on a whole class of inputs. The same zero-group check was applied to the separate IPv6 parser inside b.guardCidr, and the embedded IPv4 tail of an IPv4-mapped IPv6 address is now validated with the framework's strict dotted-quad check so a leading-zero / octal-ambiguous octet (for example ::ffff:01.2.3.4) is refused instead of reinterpreted. Legitimate compressed and IPv4-mapped addresses are unchanged.
 
 - v0.16.29 (2026-07-13) — **Reject a backup manifest's absolute, drive-letter, or NTFS-stream path at validation and resolve every path through the framework path-safety primitive on both backup and restore, and stop a bound-key auth middleware from hanging when a required peer certificate is absent.** Two defects surfaced while covering the backup/restore path handling and the bound-key auth middleware. A backup manifest's file paths were checked only for a leading separator and .., so a Windows drive-letter path such as C:\Windows\evil, or a colon-bearing NTFS alternate-data-stream marker such as db.enc:evil, passed b.backupManifest.validate, and the backup and restore steps joined the caller- or manifest-declared relativePath and encryptedPath directly, without the framework's path-safety primitive -- so a path built from untrusted input could read a file outside dataDir on backup, or aim a restored file (or a blob read) outside the staging directory on restore. validate now rejects a colon anywhere (both the drive-letter prefix and the alternate-data-stream marker) alongside .. and a leading separator, and both b.backupBundle.create and b.restoreBundle resolve every manifest-declared path through b.safePath (which refuses traversal, absolute, drive-letter, UNC, NTFS alternate-data-stream, and reserved-name paths), so each sink is contained even if a path slips past the first-line check. Separately, b.middleware.requireBoundKey dereferenced req.peerCert.raw in its peer-certificate pinning branch when a fingerprint had been pre-attached by upstream mTLS but the certificate object was absent, throwing an uncaught TypeError that rejected the middleware promise -- the request hung with no response instead of a clean fail-closed denial; the branch now guards the certificate and denies. **Fixed:** *b.middleware.requireBoundKey fails closed instead of hanging when a required peer certificate is absent* — In the peer-certificate pinning branch, the middleware read req.peerCert.raw without checking that req.peerCert was present. When an upstream mTLS layer had pre-attached a peer fingerprint (req.peerFingerprint) but no certificate object, that read threw an uncaught TypeError, which rejected the middleware's promise -- the request received no response and hung, rather than a clean fail-closed 401/403. The branch now checks for the certificate before dereferencing it and denies when it is missing, so a peer-cert-pinned key without a usable certificate is refused, not stalled. **Security:** *Backup and restore resolve every filesystem path through b.safePath, and b.backupManifest.validate rejects an absolute, drive-letter, or NTFS-stream path* — A backup manifest's per-file relativePath and encryptedPath were validated only against .. and a leading / or \, so a Windows drive-absolute path (C:\...) or an NTFS alternate-data-stream marker (db.enc:evil) passed b.backupManifest.validate, and the backup, restore, and storage-adapter steps built their filesystem paths with a plain path join of the caller- or manifest-supplied values -- meaning a path built from untrusted input could read a file outside dataDir on backup, aim a decrypted-file write or an encrypted-blob read outside the intended directory on restore, or escape the storage root through the filesystem adapter. validate() now rejects a colon anywhere (covering both the drive-letter prefix and the alternate-data-stream marker) alongside .. and a leading separator, and every filesystem sink -- b.backupBundle.create (the source read), b.restoreBundle (the encrypted-blob read and the restore destination), and the b.backup.bundleAdapterStorage.fsAdapter key resolver -- resolves its path through b.safePath, which refuses traversal, absolute, drive-letter, UNC, NTFS alternate-data-stream, and Windows reserved-name components and contains the result under its base. (The object-store storage adapter builds an object key, not a filesystem path, and keeps its traversal/NUL check -- a colon is a legal object-key character.) Legitimate relative paths back up and restore unchanged.

package/lib/vendor/MANIFEST.json

@@ -12,13 +12,13 @@
       "files": {
         "server": "lib/vendor/noble-ciphers.cjs"
       },
-      "bundler": "esbuild --format=cjs --minify --platform=node",
-      "bundledAt": "2026-04-25T00:00:00Z",
+      "bundler": "esbuild --format=cjs --platform=node",
+      "bundledAt": "2026-07-13T00:00:00Z",
       "cpe": "cpe:2.3:a:paulmillr:noble-ciphers:2.2.0:*:*:*:*:node.js:*:*",
       "hashes": {
-        "server": "sha256:5d539dfc9ef47121d4c09bd7256d76448a1f5ac47ee09ac44c78ff6a062af9ab"
+        "server": "sha256:2b30a26f728c5349f4c4b47834f862a4f77393b1224fc12b22abe3ce2cfab78f"
       },
-      "refreshedAt": "2026-07-13T22:58:54.983Z"
+      "refreshedAt": "2026-07-14T02:30:39.604Z"
     },
     "@noble/curves": {
       "version": "2.2.0",
@@ -34,13 +34,13 @@
       "files": {
         "server": "lib/vendor/noble-curves.cjs"
       },
-      "bundler": "esbuild --format=cjs --minify --platform=node",
-      "bundledAt": "2026-05-26T00:00:00Z",
+      "bundler": "esbuild --format=cjs --platform=node",
+      "bundledAt": "2026-07-13T00:00:00Z",
       "cpe": "cpe:2.3:a:paulmillr:noble-curves:2.2.0:*:*:*:*:node.js:*:*",
       "hashes": {
-        "server": "sha256:ebf254d5eb56aef8705a1c4af9603f47987b4870a9bb5e657e06907b701e2731"
+        "server": "sha256:2880c288b1285ef51d356d057bee6f0c8a00de36638cf47b47617e8c1faf10d5"
       },
-      "refreshedAt": "2026-07-13T22:58:54.983Z"
+      "refreshedAt": "2026-07-14T02:30:39.604Z"
     },
     "@noble/post-quantum": {
       "version": "0.6.1",
@@ -65,13 +65,13 @@
       "files": {
         "server": "lib/vendor/noble-post-quantum.cjs"
       },
-      "bundler": "esbuild --format=cjs --minify --platform=node",
-      "bundledAt": "2026-05-06T00:00:00Z",
+      "bundler": "esbuild --format=cjs --platform=node",
+      "bundledAt": "2026-07-13T00:00:00Z",
       "cpe": "cpe:2.3:a:paulmillr:noble-post-quantum:0.6.1:*:*:*:*:node.js:*:*",
       "hashes": {
-        "server": "sha256:f9190309daadca4c2e2cc2b76beaa6b96e463429cc3c390bd9f0ceaf7b588c68"
+        "server": "sha256:f9c94094b3c10fe73dac5343289da582454ea6053494fab2bf66099d9103d6c3"
       },
-      "refreshedAt": "2026-07-13T22:58:54.983Z"
+      "refreshedAt": "2026-07-14T02:30:39.604Z"
     },
     "@simplewebauthn/server": {
       "version": "13.3.2",
@@ -88,13 +88,13 @@
       "files": {
         "server": "lib/vendor/simplewebauthn-server.cjs"
       },
-      "bundler": "esbuild --format=cjs --minify --platform=node --external:crypto --external:node:crypto",
-      "bundledAt": "2026-06-24T00:00:00Z",
+      "bundler": "esbuild --format=cjs --platform=node --alias:reflect-metadata=reflect-metadata/lite --external:crypto --external:node:crypto",
+      "bundledAt": "2026-07-13T00:00:00Z",
       "cpe": "cpe:2.3:a:simplewebauthn:server:13.3.2:*:*:*:*:node.js:*:*",
       "hashes": {
-        "server": "sha256:49411d893f5e9b0e2fcaa564b4ec7921f73a9a06229b5e53d49c1453ea1a365c"
+        "server": "sha256:e83195dc9f189385da9c856ef38843f4466f93ea8f3d7fc2efcb1e1b18da6f20"
       },
-      "refreshedAt": "2026-07-13T22:58:54.983Z"
+      "refreshedAt": "2026-07-14T02:30:39.604Z"
     },
     "SecLists-common-passwords-top-10000": {
       "version": "10k-most-common (master)",
@@ -114,7 +114,7 @@
       },
       "runtime_artifact": "lib/vendor/common-passwords-top-10000.data.js",
       "integrity_layers": "sha256 + sha3-512 + SLH-DSA-SHAKE-256f signature + in-payload canary (where applicable)",
-      "refreshedAt": "2026-07-13T22:58:54.983Z"
+      "refreshedAt": "2026-07-14T02:30:39.604Z"
     },
     "bimi-trust-anchors": {
       "version": "operator-managed",
@@ -139,7 +139,7 @@
       },
       "runtime_artifact": "lib/vendor/bimi-trust-anchors.data.js",
       "integrity_layers": "sha256 + sha3-512 + SLH-DSA-SHAKE-256f signature + in-payload canary (where applicable)",
-      "refreshedAt": "2026-07-13T22:58:54.983Z"
+      "refreshedAt": "2026-07-14T02:30:39.604Z"
     },
     "publicsuffix-list": {
       "version": "master",
@@ -159,7 +159,7 @@
       },
       "runtime_artifact": "lib/vendor/public-suffix-list.data.js",
       "integrity_layers": "sha256 + sha3-512 + SLH-DSA-SHAKE-256f signature + in-payload canary (where applicable)",
-      "refreshedAt": "2026-07-13T22:58:54.983Z"
+      "refreshedAt": "2026-07-14T02:30:39.604Z"
     },
     "peculiar-pki": {
       "version": "2.0.0+pkijs-3.4.0",
@@ -185,12 +185,12 @@
       "files": {
         "server": "lib/vendor/pki.cjs"
       },
-      "bundler": "esbuild --format=cjs --minify --platform=node --external:crypto --external:node:crypto",
-      "bundledAt": "2026-04-29T00:00:00Z",
+      "bundler": "esbuild --format=cjs --platform=node --alias:reflect-metadata=reflect-metadata/lite --external:node:crypto --external:crypto",
+      "bundledAt": "2026-07-13T00:00:00Z",
       "hashes": {
-        "server": "sha256:9bbc191afaaa2b1e5757f00480457c08134cdc2c55d541df18d9155bba9cbf77"
+        "server": "sha256:2307ef65e070757ffb13442b377e45efb9fa1a10432d9b39618387720ab990ed"
       },
-      "refreshedAt": "2026-07-13T22:58:54.983Z"
+      "refreshedAt": "2026-07-14T02:30:39.604Z"
     }
   }
 }