@blamejs/core 0.16.5 → 0.16.6

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.16.x
 
+- v0.16.6 (2026-07-05) — **Repair the ClusterFuzzLite / OSS-Fuzz build script so its fuzz targets actually install the jazzer.js runtime and pair with their seed corpora.** This patch fixes the OSS-Fuzz / ClusterFuzzLite build script (.clusterfuzzlite/build.sh), which was latently broken: it compiled every fuzz/<name>.fuzz.js harness without first installing @jazzer.js/core, so the generated targets referenced a runtime that was never present and could not start, and it named each seed-corpus archive after the .fuzz.js-stripped base (guard-csv_seed_corpus.zip) rather than the compiled target (guard-csv.fuzz), so the fuzzing engine never associated a corpus with its target and bootstrapped from nothing. Both failures were silent because the compile step still exits 0 and the in-repo CI fuzz workflows invoke jazzer.js directly rather than through this script — the script is the OSS-Fuzz-upstream integration spec. The build script now installs the jazzer.js runtime into the project-root node_modules before compiling and names each corpus after its target, and a codebase-patterns check locks both invariants in. The build image's inline documentation is corrected (jazzer.js is not present in the base image; the CI workflows do not consume this image) and now records why the upstream path is still latent (the base image ships Node 20 / GLIBC 2.31, below the framework's Node 22+ and jazzer.js's GLIBC 2.38 needs). No shipped framework code changes; fuzz and build-image assets are dev-only and are not part of the published package. **Fixed:** *OSS-Fuzz / ClusterFuzzLite build script installs the jazzer.js runtime before compiling* — compile_javascript_fuzzer emits a runnable that executes <project>/node_modules/@jazzer.js/core at fuzz time from a wholesale copy of the source tree, so the runtime must exist in the project-root node_modules at compile time. The build script never ran an install, so @jazzer.js/core (declared in fuzz/package.json) was absent and every compiled target referenced a runtime that wasn't there. The script now installs it before the compile loop. · *Fuzz seed corpora are paired with their compiled target* — compile_javascript_fuzzer names each target after basename -s .js (keeping the .fuzz stem, e.g. guard-csv.fuzz), but the script zipped each seed corpus under the .fuzz.js-stripped base (guard-csv_seed_corpus.zip). The fuzzing engine pairs <target>_seed_corpus.zip, so no corpus was ever associated and targets started from an empty corpus. Each corpus is now named after its target. · *Build-image documentation corrected* — The build image's comments claimed jazzer.js was pre-installed in the base image and that the CI fuzz workflows consume this image; neither is true. The comments now state that build.sh installs jazzer.js and that the CI workflows invoke jazzer.js directly, and record that the OSS-Fuzz-upstream path remains latent until the base image advances to Node 24 / a newer GLIBC. **Detectors:** *Fuzz-build invariants checked in codebase-patterns* — A cross-artifact check asserts that .clusterfuzzlite/build.sh installs a jazzer.js runtime before compile_javascript_fuzzer and names each seed-corpus archive after the compiled target, so neither gap can silently reappear.
+
 - v0.16.5 (2026-07-03) — **Correctness fixes across the ReDoS guard, Base32 codec, HTTP multipart builder, SAML encrypted-assertion decryption, and the OAuth device grant — several restore advertised functionality that was silently non-working, plus a multipart header-injection fix.** This patch fixes a batch of correctness and security defects, several of which restore advertised behaviour that never actually worked. The ReDoS guard (b.guardRegex) no longer false-rejects LINEAR patterns that use a quantified non-capturing group (`(?:…)?`, `(?:…)*`) or an optional quantified group (`(X+)?`, `(?:X+)?`) — those repeat the group at most once and are not catastrophic; the detector now correctly requires the OUTER quantifier to be unbounded, so operator regex screening and b.selfUpdate asset patterns that use an optional SemVer suffix work again while genuine `(a+)+` shapes are still refused. The Base32 decoder now rejects NON-CANONICAL input (a final symbol whose unused low bits are non-zero — previously two distinct strings decoded to the same bytes, a malleability problem for the TOTP secrets and identifiers Base32 backs) and impossible symbol counts (1/3/6 mod 8 that silently produced a truncated buffer). The HTTP multipart/form-data builder now refuses CR/LF/NUL in a field name, filename, or content-type, closing a part-header-injection / form-part-forgery path. Two SAML EncryptedAssertion decryption paths that were completely dead — ML-KEM-1024 key transport and XChaCha20-Poly1305 content — are fixed (they referenced crypto entry points that were never exported, so the framework's advertised PQC-first / AEAD SAML encryption always failed and misreported the cause as a wrong-key or tag-mismatch error). The OAuth device grant now works against spec-compliant identity providers (its poll aborted on the first `authorization_pending`, which RFC 8628 delivers as an HTTP 400 the client was rejecting before reading), and a static (non-discovery) OAuth client can now use introspection, dynamic registration, and device authorization by configuring those endpoints. Smaller fixes round it out: the HTTP client's default error carries statusCode/permanent; the CLI dev server's repeatable flags accumulate; DANE and MTA-STS failures are scoped correctly per RFC; and typed errors replace raw TypeErrors on a couple of malformed-input paths. **Fixed:** *HTTP client default error carries statusCode and permanent* — request() fell back to the base FrameworkError when no explicit opts.errorClass was passed, so error.statusCode and error.permanent were undefined on the default path despite the documented default of HttpClientError. The default is now HttpClientError, so those fields are populated for every consumer. · *Static OAuth clients can configure introspection / registration / device-authorization endpoints* — create() never read opts.introspectionEndpoint / registrationEndpoint / deviceAuthorizationEndpoint into its static-endpoint set, so introspectToken / registerClient / deviceAuthorization resolved those endpoints only via OIDC discovery — a static (non-discovery) client could not use them, even though introspectToken's own error told operators to set the endpoint on create(). Those three endpoints are now honored from static config. · *CLI dev server repeatable flags accumulate* — `blamejs dev --arg / --watch / --ignore` are documented repeatable, but the argument parser overwrote each on repeat, so only the last occurrence survived — only the last --watch directory was monitored, only the last --ignore applied, and the child received only the last --arg. Repeated occurrences of these flags now accumulate as documented. · *DANE per-recipient failure isolation and MTA-STS testing-mode handling* — A DANE-enforce TLSA-lookup failure threw out of the entire deliver() batch instead of failing just the one recipient; it now fails that recipient and lets the rest proceed. And an MTA-STS policy published in `testing` mode was hard-bounced under the default enforce posture, violating RFC 8461 §5.2 (testing mode is report-only); a testing-mode policy no longer blocks delivery. · *external-db validates defaultBackend and enforces the pool min floor* — init() did not validate that opts.defaultBackend named a registered backend, so a typo surfaced as an opaque TypeError at the first query instead of a typed config-time error; it is now validated at init. The pool `min` (documented as a floor on idle clients) was never enforced; the reaper now respects it. · *mail-bounce returns a typed error for a null SES SNS message* — An SES SNS notification whose Message field is JSON literal `null` dereferenced null and threw a raw TypeError (also risking an internal-message leak); it now throws the typed MailBounceError like the other malformed-input paths. **Security:** *b.guardRegex no longer false-rejects linear quantified-group patterns (#432, #429)* — The nested-quantifier ReDoS detector treated the `?` in a `(?:` group prefix as an inner quantifier and treated a bounded outer `?` / `{0,1}` as a dangerous outer quantifier, so it wrongly refused LINEAR patterns like `^(?:/page/\d+)?$`, `^foo(?:bar)*$`, `^(a+)?$`, and `(?:[-+][0-9A-Za-z.-]+)?`. The catastrophic class requires the OUTER quantifier to be unbounded (`*`/`+`/`{n,}`). The detector now relies solely on the paren-aware structural scanner, which requires an unbounded outer quantifier and does not miscount a group prefix — so genuine `(a+)+` / `((a)+)+` shapes stay refused while these linear ones are accepted. Consumers screening operator-supplied regexes (route rules, and b.selfUpdate asset patterns using an optional SemVer prerelease/build group) are no longer forced to rewrite valid input. · *Base32 decoder rejects non-canonical encodings and impossible lengths* — b.base32.decode discarded the final symbol's unused low bits without checking they were zero (RFC 4648 §3.5), so two distinct strings — e.g. `MY======` and `MZ======` — decoded to the same bytes (decoder malleability), and it silently accepted impossible symbol counts (1/3/6 mod 8) that can't represent whole bytes, returning a truncated buffer. Both are now refused (`base32/non-canonical`, `base32/bad-length`), giving a one-to-one mapping between a byte sequence and its Base32 string — important where the string is a key / secret / dedup handle (TOTP, identifiers). Valid input, including unpadded and loose-mode input, is unaffected. · *HTTP multipart/form-data builder refuses CR/LF/NUL in part-header values* — The multipart body builder interpolated the field name, file field, filename, and content-type onto `Content-Disposition:` / `Content-Type:` part-header lines without a control-character check, so an attacker controlling one of those values could smuggle a CRLF and inject additional part headers or forge form parts. CR, LF, and NUL in any of those values are now refused, matching the header-safety the mail-header sweep already applies to RFC 822 lines. · *SAML EncryptedAssertion ML-KEM-1024 and XChaCha20-Poly1305 decryption now work* — verifyResponse's post-quantum key-transport branch and its XChaCha20-Poly1305 content branch called crypto entry points that the crypto module never exported, so every ML-KEM-1024-wrapped or XChaCha20-Poly1305-encrypted SAML assertion failed with an internal TypeError that was re-reported as a key-unwrap or tag-mismatch error — the advertised PQC-first / AEAD SAML encryption was dead. Both paths now route through the exported envelope-open and packed-AEAD primitives, verified with a full encrypt→decrypt round trip. Fails closed (no auth bypass) either way. · *OAuth device grant polls correctly against spec-compliant providers* — pollDeviceCode issued its token request in the default buffering mode, so the HTTP client rejected the HTTP 400 that RFC 8628 §3.5 / RFC 6749 §5.2 use to carry `authorization_pending` / `slow_down` before the poll loop could read the OAuth error body — the grant aborted on the first poll (which is almost always `authorization_pending`, since the user hasn't approved yet). The request now resolves 4xx OAuth error responses so the pending / slow-down / terminal handling runs and the device grant completes.
 
 - v0.16.4 (2026-07-03) — **A CalDAV/CardDAV path-traversal fix, an SMTP BDAT body-corruption fix, and a database-stream off-by-one — plus five smaller robustness fixes — surfaced by a large expansion of command-handler and error-branch test coverage across the mail servers, DNS, TLS and database primitives.** This patch fixes a batch of defects concentrated in the error and adversarial-input paths of the mail-server, DNS, TLS and database primitives, found while substantially expanding the automated test suite over their command handlers and failure branches. The most serious is a CalDAV/CardDAV path-traversal: the request-path guard rejected a literal `..` or `%2e%2e` before decoding, but each path segment was then percent-decoded and handed to the storage backend — so a MIXED encoding such as `.%2e` (neither form the guard checks) slipped through and decoded to `..`, reaching the operator's storage backend with a traversal segment. Path segments are now validated AFTER decoding. On the SMTP submission path, the message body was dot-stuffed (SMTP DATA transparency) inside the message builder and that same body was reused for RFC 3030 BDAT/CHUNKING chunks — which are length-framed and are NOT un-stuffed by the receiver — so any body line beginning with `.` was delivered with a spurious doubled dot to every peer advertising CHUNKING (Gmail/Outlook/Exchange/Postfix all do); dot-stuffing now applies only on the DATA path. The database row-streamer had an off-by-one: a result set of exactly `streamLimit` rows errored with `db/stream-limit-exceeded` instead of completing, because the cap was checked before the iterator could report done — so a valid, complete export surfaced as a stream error. Five smaller fixes round it out: CalDAV/CardDAV now return 400 (not 500) for a malformed/empty client request body; `dns.resolve` rejects a non-string record type with a typed error instead of an untyped TypeError; the DNS negative cache is honored when an explicit negative TTL is set even if the positive TTL is 0; and the Resend mail transport handles a literal JSON `null` response body without taking a mislabeled error path. **Fixed:** *SMTP BDAT/CHUNKING no longer corrupts body lines beginning with a dot* — The RFC 822 message builder applied SMTP DATA-transparency dot-stuffing (a leading `.` on a line is doubled) to the body, and the submission transport reused that same body for RFC 3030 BDAT chunks. BDAT framing is purely length-based and receivers do NOT un-stuff it, so a body line starting with `.` was delivered with an extra leading dot to any peer advertising CHUNKING (which Gmail, Outlook, Exchange and Postfix all do — CHUNKING is default-on). Dot-stuffing is now applied only when framing via DATA; the message the builder produces (and that DKIM signs) is the un-stuffed body the receiver verifies, and the BDAT path sends it verbatim. · *db.stream no longer errors on a result set of exactly streamLimit rows* — The stream's per-read cap was checked at the top of the read callback, before the row iterator could report completion, so after emitting exactly `streamLimit` rows the next read destroyed the stream with `db/stream-limit-exceeded` even though the count never exceeded the cap — turning a valid, complete export into an error event. The cap is now enforced after pulling the next row and checking for end-of-results, so exactly-`streamLimit` rows complete cleanly and only a row BEYOND the cap trips the guard. · *CalDAV/CardDAV return 400 for a malformed or empty client request body* — A malformed PROPFIND/REPORT XML body (or an empty REPORT body) threw from the body parser into the generic dispatch catch, which unconditionally returned 500 — inconsistent with MKCALENDAR/MKCOL, which already return 400 for the same input. Client-fault body-parse errors now return 400 (Bad Request); a genuine server-side backend throw still returns 500. · *dns.resolve rejects a non-string record type with a typed error* — `dns.resolve(host, type)` called `.toUpperCase()` on whatever `type` was passed, so a non-string (e.g. a number) threw a raw `TypeError` with no code and no `.permanent` flag — unlike an unknown STRING type, which throws a typed `dns/unsupported-type`. A caller keying on the documented `err.permanent` retry contract would have read undefined (falsy) and treated an unfixable input as retryable. A non-string type is now rejected with the typed error. · *DNS negative cache honors an explicit negative TTL when the positive TTL is 0* — The negative-response cache early-returned whenever the positive `cacheTtlMs` was 0, so `setCacheTtlMs(0, 60000)` (positive caching off, negative caching 60s) silently never populated the negative cache — the accepted negative TTL was not applied. The negative cache now uses the explicit negative TTL even when the positive TTL is 0. · *Resend transport handles a literal JSON null response body* — The Resend mail transport parsed the response body then dereferenced `data.id`; a literal JSON `null` body parses to `null`, so the dereference threw a raw TypeError that was reported as an interpret failure rather than the intended bad-response verdict. A null/absent parsed body is now treated as a bad response directly. **Security:** *CalDAV/CardDAV path-traversal via mixed percent-encoding is refused* — `_parsePath` rejected a literal `..`, `%2e%2e`, `%00` or NUL in the RAW request path, but then percent-decoded each segment and passed the decoded value (principalId / collection / component id) straight to the storage backend (getComponent / putComponent / listComponents / …). A mixed encoding such as `.%2e` or `%2e.` contains neither a literal `..` nor `%2e%2e`, so it passed the pre-decode guard and decoded to `..`, reaching the backend with a traversal segment. Each segment is now validated AFTER decoding — any decoded `.` / `..` / NUL / embedded path separator is refused — matching the decode-once-then-validate discipline the router already applies.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/core",
-  "version": "0.16.5",
+  "version": "0.16.6",
   "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:f9a1389c-b576-4d1a-8d0e-33d85c815fb6",
+  "serialNumber": "urn:uuid:58bdc6e3-f682-4982-908d-0f427322f002",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-07-04T07:19:07.771Z",
+    "timestamp": "2026-07-06T05:51:57.162Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/core@0.16.5",
+      "bom-ref": "@blamejs/core@0.16.6",
       "type": "application",
       "name": "blamejs",
-      "version": "0.16.5",
+      "version": "0.16.6",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "The Node framework that owns its stack.",
-      "purl": "pkg:npm/%40blamejs/core@0.16.5",
+      "purl": "pkg:npm/%40blamejs/core@0.16.6",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/core@0.16.5",
+      "ref": "@blamejs/core@0.16.6",
       "dependsOn": []
     }
   ]