@blamejs/blamejs-shop 0.2.15 → 0.2.17

package/lib/vendor/blamejs/lib/i18n.js

@@ -64,6 +64,15 @@ var requestHelpers = require("./request-helpers");
 var safeJson = require("./safe-json");
 var validateOpts = require("./validate-opts");
 var { I18nError } = require("./framework-error");
+var { boundedMap } = require("./bounded-map");
+
+// Per-instance formatter caches are keyed on (locale, JSON.stringify
+// formatOpts). A fixed `locales` set bounds the locale axis, but operators
+// can pass fresh formatOpts shapes per call (and `Intl` options are open-
+// ended), so the key space is request-influenced — cap it so it can't grow
+// without limit. Evict-oldest is free here: a formatter is pure-derived and
+// re-created on the next miss.
+var FORMATTER_CACHE_MAX_ENTRIES = 512;
 
 var observability = lazyRequire(function () { return require("./observability"); });
 
@@ -353,7 +362,7 @@ function _interpolate(template, vars, interpolation) {
 // only with operators handing in fresh literals every call (they
 // usually pass the same shape).
 function _makeFormatterCache(make, kind, emitObs) {
-  var cache = new Map();
+  var cache = boundedMap({ maxEntries: FORMATTER_CACHE_MAX_ENTRIES, policy: "evict-oldest" });
   return function getFormatter(locale, formatOpts) {
     var optsKey = formatOpts ? JSON.stringify(formatOpts) : "";
     var cacheKey = locale + "\x1f" + optsKey;

package/lib/vendor/blamejs/lib/mail-crypto-smime.js

@@ -386,6 +386,25 @@ function _verifySignerInfo(si, msgBytes, signerPublicKey, auditHandle) {
   return { sigAlg: sigAlg, digestAlg: digestAlg };
 }
 
+// Does this cert's public key match the raw signer key that verified the
+// signature? signerBytes is the key passed to the PQC/classical verify; a
+// cert exposes its key as SPKI DER. The raw subjectPublicKey is the tail of
+// the SPKI (its last element), so a suffix match catches the raw-key form
+// while a full-length compare catches a caller who passed the SPKI itself.
+// If the key can't be exported (an algorithm this Node build can't parse),
+// the cert can't be bound — return false so the caller fails closed rather
+// than trusting an unverifiable binding.
+function _certKeyMatches(cert, signerBytes) {
+  var spki;
+  try { spki = Buffer.from(cert.publicKey.export({ format: "der", type: "spki" })); }
+  catch (_e) { return false; }
+  if (spki.length === signerBytes.length) return Buffer.compare(spki, signerBytes) === 0;
+  if (signerBytes.length < spki.length) {
+    return Buffer.compare(spki.subarray(spki.length - signerBytes.length), signerBytes) === 0;
+  }
+  return false;
+}
+
 function _verifyTrustChain(sd, trustAnchorCertsPem, signerPublicKey, auditHandle) {
   if (sd.certificates.length === 0) {
     throw new MailCryptoError("mail-crypto/smime/no-certs",
@@ -411,13 +430,24 @@ function _verifyTrustChain(sd, trustAnchorCertsPem, signerPublicKey, auditHandle
         "trustAnchorCertsPem[" + idx + "] parse failed: " + ((e && e.message) || String(e)));
     }
   });
-  // Pick the leaf — the cert whose public key matches the verified
-  // signature. signerPublicKey is the PQC raw bytes; we compare
-  // against each chain cert's exported jwk x / SPKI. Hardest path:
-  // PQC isn't in node:crypto X509Certificate yet, so the leaf might
-  // be ECDSA / RSA. Fall back to picking the first cert when no
-  // other comparison applies (operator's chain is operator-curated).
-  var leaf = chain[0];
+  // Bind the leaf to the key that ACTUALLY verified the signature
+  // (signerPublicKey). Without this, a validly-chained certificate for a
+  // DIFFERENT identity would pass chain validation while the signature was
+  // verified under an unrelated key — chainVerified would assert a binding
+  // the code never made. Find the chain cert whose public key matches
+  // signerPublicKey; if none does, the supplied chain does not correspond
+  // to the verified signer, so fail closed.
+  var signerBytes = Buffer.from(signerPublicKey);
+  var leaf = null;
+  for (var lci = 0; lci < chain.length; lci += 1) {
+    if (_certKeyMatches(chain[lci], signerBytes)) { leaf = chain[lci]; break; }
+  }
+  if (!leaf) {
+    throw new MailCryptoError("mail-crypto/smime/signer-not-in-chain",
+      "trust-chain validation: no certificate in SignedData.certificates carries the " +
+      "public key that verified the signature — the supplied chain does not correspond " +
+      "to the verified signer");
+  }
   // Validity window check (RFC 5280 §4.1.2.5) — every cert in chain
   // must be within validFrom..validTo at the current wall-clock.
   var nowMs = Date.now();
@@ -444,8 +474,8 @@ function _verifyTrustChain(sd, trustAnchorCertsPem, signerPublicKey, auditHandle
       if (current.issuer === r.subject) {
         try {
           if (current.verify(r.publicKey)) {
-            void signerPublicKey; void auditHandle;
-            return;   // chain validates
+            void auditHandle;
+            return;   // chain validates (and the leaf is the verified signer)
           }
         } catch (_e) { /* fall through to next root */ }
       }
@@ -787,4 +817,8 @@ module.exports = {
   ALLOWED_HASHES:      ALLOWED_HASHES,
   REFUSED_HASHES:      REFUSED_HASHES,
   RSA_MIN_BITS:        RSA_MIN_BITS,
+  // Exposed for tests — the leaf↔signer-key binding used by trust-chain
+  // validation (a cert matches the verified signer key iff its SPKI public
+  // key equals, or has as a suffix, the raw signer key bytes).
+  _certKeyMatches:     _certKeyMatches,
 };

package/lib/vendor/blamejs/lib/network-dns.js

@@ -13,6 +13,7 @@ var safeBuffer = require("./safe-buffer");
 var safeUrl = require("./safe-url");
 var validateOpts = require("./validate-opts");
 var { defineClass } = require("./framework-error");
+var { boundedMap } = require("./bounded-map");
 
 var DnsError = defineClass("DnsError", { alwaysPermanent: false });
 
@@ -89,8 +90,15 @@ function _ensureSecureDefault() {
   STATE.doh = { url: DEFAULT_DOH_URL, method: null, ca: null };
 }
 
-var POSITIVE_CACHE = new Map();
-var NEGATIVE_CACHE = new Map();
+// Resolver caches are keyed on (hostname, family). Hostnames reaching the
+// resolver are request-influenced (outbound HTTP targets, mail MX lookups,
+// operator-supplied URLs), and expired entries are only reclaimed lazily on
+// a re-query of the SAME key — so a stream of unique hostnames would grow
+// these without bound. Cap them; evict-oldest is free (DNS re-resolves on
+// the next miss). The cap bounds peak memory even with no periodic sweep.
+var DNS_CACHE_MAX_ENTRIES = 4096;
+var POSITIVE_CACHE = boundedMap({ maxEntries: DNS_CACHE_MAX_ENTRIES, policy: "evict-oldest" });
+var NEGATIVE_CACHE = boundedMap({ maxEntries: DNS_CACHE_MAX_ENTRIES, policy: "evict-oldest" });
 
 function _now() { return Date.now(); }
 

package/lib/vendor/blamejs/lib/nonce-store.js

@@ -45,10 +45,18 @@ var clusterStorage = require("./cluster-storage");
 var C = require("./constants");
 var safeAsync = require("./safe-async");
 var { defineClass } = require("./framework-error");
+var { boundedMap } = require("./bounded-map");
 
 var NonceStoreError = defineClass("NonceStoreError");
 
 var DEFAULT_SWEEP_INTERVAL_MS = C.TIME.minutes(5);
+// Memory-backend ceiling. Each request carries an attacker-choosable unique
+// nonce, so between sweeps the store would otherwise grow without bound (a
+// memory-amplification DoS). Capped — but a replay-protection store must
+// NOT evict a live nonce to admit a new one (that reopens a replay window
+// for the evicted nonce), so the cap uses the "reject" policy and the
+// backend fails CLOSED at capacity (see checkAndInsert).
+var DEFAULT_MAX_ENTRIES = 1000000;
 
 function _err(code, message) {
   return new NonceStoreError(code, message, true);
@@ -58,14 +66,22 @@ function _err(code, message) {
 
 function _memoryBackend(opts) {
   var sweepIntervalMs = opts.sweepIntervalMs || DEFAULT_SWEEP_INTERVAL_MS;
-  var seen = new Map();   // nonce -> expireAt
+  var maxEntries = opts.maxEntries || DEFAULT_MAX_ENTRIES;
+  // policy "reject" — never evict a live nonce (that would reopen a replay
+  // window for the dropped one). At capacity the backend fails closed.
+  var seen = boundedMap({ maxEntries: maxEntries, policy: "reject" });
+  var capacityRejects = 0;
 
-  var sweepTimer = safeAsync.repeating(function () {
+  function _purgeExpiredSync() {
     var now = Date.now();
+    var removed = 0;
     for (var entry of seen) {
-      if (entry[1] <= now) seen.delete(entry[0]);
+      if (entry[1] <= now) { seen.delete(entry[0]); removed++; }
     }
-  }, sweepIntervalMs, { name: "nonce-sweep" });
+    return removed;
+  }
+
+  var sweepTimer = safeAsync.repeating(_purgeExpiredSync, sweepIntervalMs, { name: "nonce-sweep" });
 
   function checkAndInsert(nonce, expireAt) {
     if (typeof nonce !== "string" || nonce.length === 0) {
@@ -78,17 +94,26 @@ function _memoryBackend(opts) {
     if (existing !== undefined && existing > Date.now()) {
       return Promise.resolve(false);   // replay
     }
-    seen.set(nonce, expireAt);
+    var stored = seen.set(nonce, expireAt);
+    if (!stored) {
+      // At capacity. Reclaim expired entries inline, then retry once.
+      _purgeExpiredSync();
+      stored = seen.set(nonce, expireAt);
+    }
+    if (!stored) {
+      // Still full of LIVE nonces — a genuine flood. FAIL CLOSED: we
+      // cannot record this nonce, so we cannot prove it is first-seen.
+      // Refuse it (report as "seen") rather than admit an unprotected
+      // request. Evicting a live nonce to make room would reopen a replay
+      // window, so we never evict — the request is rejected instead.
+      capacityRejects += 1;
+      return Promise.resolve(false);
+    }
     return Promise.resolve(true);
   }
 
   function purgeExpired() {
-    var now = Date.now();
-    var removed = 0;
-    for (var entry of seen) {
-      if (entry[1] <= now) { seen.delete(entry[0]); removed++; }
-    }
-    return Promise.resolve(removed);
+    return Promise.resolve(_purgeExpiredSync());
   }
 
   function close() {
@@ -101,8 +126,10 @@ function _memoryBackend(opts) {
     checkAndInsert:  checkAndInsert,
     purgeExpired:    purgeExpired,
     close:           close,
-    // Test hook — direct read of the underlying Map size
+    // Test hooks — underlying entry count + count of capacity fail-closed
+    // rejections (a nonce flood that hit the ceiling).
     _size:           function () { return seen.size; },
+    _capacityRejects: function () { return capacityRejects; },
   };
 }
 

package/lib/vendor/blamejs/lib/queue-local.js

@@ -88,7 +88,7 @@ function _shapeLeasedRow(raw) {
   return {
     jobId:          unsealed._id,
     queueName:      unsealed.queueName,
-    payload:        unsealed.payload ? safeJson.parse(unsealed.payload) : null,
+    payload:        unsealed.payload ? safeJson.parse(unsealed.payload, { maxBytes: C.BYTES.mib(64) }) : null,
     attempts:       Number(unsealed.attempts),
     maxAttempts:    Number(unsealed.maxAttempts),
     traceId:        unsealed.traceId,
@@ -270,7 +270,7 @@ function create(_config) {
         var cron = scheduler.parseCron(unsealedRow.repeatCron);
         var nextMs = scheduler.nextCronFire(cron, new Date(nowMs), unsealedRow.repeatTimezone || null);
         await enqueue(unsealedRow.queueName,
-          unsealedRow.payload ? safeJson.parse(unsealedRow.payload) : null,
+          unsealedRow.payload ? safeJson.parse(unsealedRow.payload, { maxBytes: C.BYTES.mib(64) }) : null,
           {
             // availableAt is the precise next-fire ms — pass it alone.
             // Don't also pass delaySeconds (the v0.6.22 / v0.6.23 fix

package/lib/vendor/blamejs/lib/redis-client.js

@@ -182,6 +182,11 @@ function create(opts) {
   var connected = false;
   var connecting = false;
   var closing = false;
+  // Tracked + unref'd reconnect timer. Tracked so close() can cancel a
+  // pending backoff (otherwise a reconnect scheduled before close fires
+  // after it and opens a fresh socket); unref'd so a backoff window doesn't
+  // by itself keep the event loop alive (the process-won't-exit class).
+  var reconnectTimer = null;
   var rxBuffer = Buffer.alloc(0);
   // FIFO of in-flight commands awaiting a response
   var pending = [];
@@ -210,7 +215,11 @@ function create(opts) {
     }
     reconnectAttempt++;
     var delay = Math.min(C.TIME.seconds(30), 100 * Math.pow(2, reconnectAttempt - 1));
-    setTimeout(function () { _connect().catch(function () { /* will reschedule */ }); }, delay);
+    reconnectTimer = setTimeout(function () {
+      reconnectTimer = null;
+      _connect().catch(function () { /* will reschedule */ });
+    }, delay);
+    if (typeof reconnectTimer.unref === "function") reconnectTimer.unref();
   }
 
   function _drainPending(err) {
@@ -290,6 +299,9 @@ function create(opts) {
   }
 
   async function _connect() {
+    // A reconnect timer scheduled before close() can still fire afterward;
+    // refuse to re-open once closing so it doesn't leak a fresh socket.
+    if (closing) return;
     if (connected) return;
     if (connecting) {
       // Wait until current connect attempt resolves
@@ -423,6 +435,7 @@ function create(opts) {
 
   async function close() {
     closing = true;
+    if (reconnectTimer) { clearTimeout(reconnectTimer); reconnectTimer = null; }
     var err = _err("CLOSED", "redis client closed");
     _drainPending(err);
     if (socket) {

package/lib/vendor/blamejs/lib/subject.js

@@ -257,6 +257,11 @@ function rectify(subjectId, opts) {
  * override an active hold (FRCP Rule 26/37(e), GDPR Art 17(3)(e),
  * SEC Rule 17a-4, HIPAA §164.530(j)(2)).
  *
+ * Security: any `actor` recorded here is an audit-record field, NOT
+ * authentication. This primitive gates the deletion on acknowledgements
+ * and the legal-hold registry, not on caller identity — the caller MUST be
+ * authenticated and authorized by your route before invoking.
+ *
  * Returns `{ rowsDeleted, perTable }`. Use `b.subject.eraseHard` when
  * residual ciphertext in WAL / replicas / backups must also be made
  * undecryptable.
@@ -383,7 +388,9 @@ function erase(subjectId, opts) {
  * Art. 17 erasure shape the framework offers.
  *
  * Same legal-hold + acknowledgement gates as `b.subject.erase`.
- * Leader-only. Returns `{ rowsDeleted, perRowKeysDestroyed, perTable }`.
+ * Security: the `actor` is an audit-record field, not authentication —
+ * authorize the caller upstream. Leader-only.
+ * Returns `{ rowsDeleted, perRowKeysDestroyed, perTable }`.
  *
  * @opts
  *   reason:           string,    // ticket reference recorded in the audit event

package/lib/vendor/blamejs/package.json

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

package/lib/vendor/blamejs/release-notes/v0.13.33.json

@@ -0,0 +1,26 @@
+{
+  "$schema": "../scripts/release-notes-schema.json",
+  "version": "0.13.33",
+  "date": "2026-05-28",
+  "headline": "Encrypted-mode DB recovers from a corrupt tmpfs working copy instead of crash-looping",
+  "summary": "In encrypted-at-rest mode the live SQLite copy is decrypted into a tmpfs working file and re-encrypted to db.enc periodically. If that working copy was corrupted (an unclean shutdown, or a full tmpfs — Docker's /dev/shm defaults to 64 MiB), the boot path trusted it because its mtime was newer than db.enc, so db.init failed its integrity gate with \"database disk image is malformed\" identically on every boot — an unrecoverable crash loop. db now integrity-probes the newer working copy before trusting it: if it is unreadable, the working copy is discarded and db.enc (the last-good encrypted snapshot) is re-decrypted, so the next boot self-heals. db.enc is never modified by this path, and a genuinely-corrupt db.enc still fails loudly rather than wiping data. The boot error on an unreadable database is now actionable (it names the tmpfs-size cause and the recovery). The wiki production compose also gains the storage settings encrypted mode needs.",
+  "sections": [
+    {
+      "heading": "Fixed",
+      "items": [
+        {
+          "title": "Corrupt tmpfs working copy no longer causes a boot crash loop (encrypted-at-rest mode)",
+          "body": "`db.init`'s crash-recovery path preferred a newer tmpfs working copy over `db.enc` unconditionally. When that copy was corrupt (truncated by an unclean shutdown or a full `/dev/shm`), every boot trusted it and failed the integrity gate the same way — an unrecoverable loop. The newer working copy is now integrity-probed (`PRAGMA quick_check`); if it is unreadable it is discarded and `db.enc` — the last-good encrypted snapshot — is re-decrypted, so boot self-heals. `db.enc` is never modified, so this only ever rolls back to the persistent copy; if `db.enc` is also corrupt, boot still fails loudly (no silent data loss). A regression test pins the recovery."
+        },
+        {
+          "title": "Actionable boot error when the database is unreadable",
+          "body": "When SQLite reports a database too corrupt to even run an integrity check, the boot error now names the likely cause and recovery instead of surfacing the raw \"database disk image is malformed\": in encrypted mode it points at the tmpfs working copy and the most common operational cause (Docker's 64 MiB `/dev/shm` default — raise it via `shm_size` / `--shm-size`), or restoring `db.enc` / the DB file from backup."
+        },
+        {
+          "title": "Wiki production compose ships the storage encrypted mode needs",
+          "body": "`examples/wiki/docker-compose.prod.yml` now sets `shm_size: '512m'` (so the encrypted-mode tmpfs working copy has headroom above Docker's 64 MiB default) and mounts a persistent `wiki-data` volume at `/data` (so `db.enc` + sealed keys survive container recreate, host reboot, and image redeploys, and give a restore point). A note flags that PaaS platforms which regenerate the compose on deploy (Coolify, Dokku, CapRover, …) must set both via the platform UI — a persistent-storage mount for `/data` and a `--shm-size 512m` custom option."
+        }
+      ]
+    }
+  ]
+}

package/lib/vendor/blamejs/release-notes/v0.13.34.json

@@ -0,0 +1,48 @@
+{
+  "$schema": "../scripts/release-notes-schema.json",
+  "version": "0.13.34",
+  "date": "2026-05-29",
+  "headline": "Corrupt TLS certs self-heal at boot, and graceful shutdown no longer loses the final DB flush",
+  "summary": "Two failure-mode fixes in the same family as the encrypted-DB recovery in 0.13.33. The cert manager treated a corrupt sealed cert or key worse than a missing one: a missing file re-issues via ACME, but a corrupt one let a raw decrypt error escape out of start(), so the same bad file was read on every boot — an unrecoverable crash loop. A corrupt sealed cert/key is now treated like an absent one and re-issued, and a corrupt derived meta.json is re-derived rather than fatal; the ACME account key (which binds order history) instead fails with an actionable error rather than a raw throw. On the shutdown side, an encrypted database that failed its final re-encrypt used to delete its plaintext working copy anyway, discarding every write since the last periodic flush; it now keeps the working copy so the next boot recovers it. The shutdown orchestrator also gains a hard-deadline watchdog: when the operator delegates signal handling to it, a phase that never settles can no longer hold the process open until the supervisor SIGKILLs it (which would skip the final DB re-encrypt) — the watchdog forces a clean exit, so exit handlers still flush. The wiki production and base compose files set a stop_grace_period above that budget so a docker stop or rolling redeploy lets the re-encrypt finish.",
+  "sections": [
+    {
+      "heading": "Fixed",
+      "items": [
+        {
+          "title": "A corrupt sealed TLS cert or key re-issues instead of crash-looping at boot",
+          "body": "`b.cert`'s start path read the sealed `cert.pem`/`key.pem` and let a raw unseal/decrypt error escape if the file was truncated or corrupt, so a managed restart read the same bad file on every boot — a crash loop, and worse handling than an absent file (which already re-issues). A corrupt sealed cert/key is now treated like a missing one: it is logged, an audit event is emitted, and the certificate is re-issued via ACME. A corrupt derived `meta.json` is likewise re-derived rather than throwing `cert/bad-meta`."
+        },
+        {
+          "title": "Unreadable ACME account key fails with an actionable error, not a raw decrypt throw",
+          "body": "Unlike a re-issuable certificate, the ACME account key binds existing order and authorization history, so it is not silently regenerated on corruption. An unreadable `account/jwk.json.sealed` now raises `cert/account-key-unreadable` naming the file and the recovery (restore from backup, or delete to register a fresh account) instead of letting a raw decrypt/parse error escape out of start()."
+        },
+        {
+          "title": "Encrypted DB keeps its working copy when the final shutdown re-encrypt fails",
+          "body": "`db.close()` re-encrypts the tmpfs working copy to `db.enc`, then deletes the working copy. If that final re-encrypt failed (a full `/dev/shm`, a full disk), the delete still ran, discarding every write since the last periodic flush and leaving only the older `db.enc`. The working copy is now kept whenever the re-encrypt fails, so the next boot's integrity-probed recovery picks up the latest writes (and still falls back to `db.enc` if the working copy is itself corrupt). `db.enc` is never modified by this path."
+        }
+      ]
+    },
+    {
+      "heading": "Changed",
+      "items": [
+        {
+          "title": "Shutdown watchdog forces a clean, DB-flushing exit if a phase hangs",
+          "body": "The graceful-shutdown orchestrator uses soft per-phase timeouts — on expiry the underlying work keeps running — so a phase that never settles could hold the event loop open past the grace window, after which a container supervisor SIGKILLs the process and skips the final DB re-encrypt. When the operator opts into signal handling, a watchdog now forces `process.exit` `graceMs + forceExitMarginMs` after the signal; exit runs the registered handlers (the DB re-encrypt), so the last flush still happens. A new `forceExitMarginMs` option (default 5000) tunes the headroom; set the container stop grace above `graceMs + forceExitMarginMs`."
+        },
+        {
+          "title": "Wiki compose sets stop_grace_period above the shutdown budget",
+          "body": "`examples/wiki/docker-compose.yml` and `docker-compose.prod.yml` now set `stop_grace_period: 40s`. Docker's 10s default would SIGKILL the container before the 30s shutdown budget reaches the DB re-encrypt phase, losing the final flush on a `docker stop` or rolling redeploy. The production note also reminds PaaS platforms that regenerate the compose (Coolify, Dokku, CapRover) to set the stop grace via the platform UI alongside the persistent-storage mount and `--shm-size`."
+        }
+      ]
+    },
+    {
+      "heading": "Detectors",
+      "items": [
+        {
+          "title": "Cross-artifact guard that stop_grace_period covers the shutdown budget",
+          "body": "A new codebase check fails if either wiki compose file omits `stop_grace_period` or sets it below the orchestrator's `graceMs` plus the watchdog margin read from `lib/app-shutdown.js`, so raising the shutdown budget without bumping the compose — or dropping the setting — cannot silently reopen the SIGKILL-before-re-encrypt data-loss window."
+        }
+      ]
+    }
+  ]
+}

package/lib/vendor/blamejs/release-notes/v0.13.35.json

@@ -0,0 +1,35 @@
+{
+  "$schema": "../scripts/release-notes-schema.json",
+  "version": "0.13.35",
+  "date": "2026-05-29",
+  "headline": "In-memory replay, idempotency, DNS, and i18n stores gain entry-count ceilings",
+  "summary": "Several framework caches keyed on request-influenced input grew without an upper bound between their periodic sweeps, so a flood of unique keys could exhaust process memory faster than the sweep reclaimed it. Each now enforces a hard entry ceiling. The replay-protection nonce store is the security-sensitive one: rather than evict a live nonce to admit a new one — which would reopen a replay window for the evicted nonce — it purges expired entries and then fails closed at capacity, refusing the unrecordable request instead of admitting it unprotected. The idempotency, DNS, and i18n caches hold re-derivable values, so they evict the oldest entry instead (the worst case is a recomputed value or a single re-executed retry under flood). Ceilings are generous defaults that normal traffic never reaches; the nonce store and the agent idempotency in-memory backend expose options to tune them.",
+  "sections": [
+    {
+      "heading": "Security",
+      "items": [
+        {
+          "title": "Replay-nonce store bounds memory and fails closed under a nonce flood",
+          "body": "The in-memory `b.nonceStore` backend recorded every request-supplied nonce until a periodic sweep ran, so a stream of unique nonces could exhaust memory between sweeps (a memory-amplification denial of service). It now caps its entry count. Because a replay-protection store must never evict a live nonce to make room — doing so would reopen a replay window for the evicted nonce — it instead purges expired entries inline and, if still at capacity with live nonces, fails closed: the new request is refused rather than admitted without replay protection. A new `maxEntries` option tunes the ceiling (default 1,000,000)."
+        }
+      ]
+    },
+    {
+      "heading": "Fixed",
+      "items": [
+        {
+          "title": "Agent idempotency in-memory backend no longer grows without bound",
+          "body": "The default in-memory backend for `b.agent.idempotency` is keyed on the request-supplied idempotency key, and its garbage collector only reclaims expired rows when an operator wires a scheduler to call it — so a flood of distinct keys could grow it until the process ran out of memory. It now caps its entry count and evicts oldest-first; a dropped record just means that one key re-executes on a later retry, never a crash. A new `maxInMemoryEntries` option tunes the ceiling (default 100,000); deployments needing a hard guarantee at scale still supply a durable `store`."
+        },
+        {
+          "title": "DNS resolver cache is bounded",
+          "body": "The positive and negative resolver caches in `b.network.dns` reclaimed an expired entry only when the same hostname was looked up again, so entries for never-requeried hostnames persisted — and hostnames reaching the resolver are request-influenced (outbound request targets, mail MX lookups). Both caches now cap their entry count and evict oldest-first; DNS simply re-resolves on the next miss."
+        },
+        {
+          "title": "i18n formatter cache is bounded",
+          "body": "Per-instance `Intl` formatter caches in `b.i18n` are keyed on the locale plus a hash of the format options. The format-options shape is open-ended and caller-supplied, so the key space was request-influenced and uncapped. The cache now enforces an entry ceiling and evicts oldest-first — a formatter is pure-derived and re-created on the next miss."
+        }
+      ]
+    }
+  ]
+}

package/lib/vendor/blamejs/release-notes/v0.13.36.json

@@ -0,0 +1,27 @@
+{
+  "$schema": "../scripts/release-notes-schema.json",
+  "version": "0.13.36",
+  "date": "2026-05-29",
+  "headline": "Certificate renewal trusts the sealed cert's own expiry, not the plaintext index",
+  "summary": "The managed-certificate renewal check decided a cached cert was still fresh by reading expiresAt from the plaintext meta.json index that sits beside the sealed cert, rather than from the certificate itself. If that index drifted from — or was tampered relative to — the actual cert (a far-future expiry recorded over a certificate that is in fact near expiry), the manager would skip renewal and keep serving a cert that was about to expire or already had. Renewal now re-derives the expiry and fingerprint from the sealed certificate itself; meta.json is treated as an advisory convenience copy. A sealed cert that no longer parses is re-issued (the same recovery as an unreadable one), and a corrupt meta.json over a valid cert now loads cleanly from the cert instead of forcing a needless re-issue. The local job queue also bounds the size of a job payload it parses back from a stored row, matching the cap the dead-letter listing already used.",
+  "sections": [
+    {
+      "heading": "Security",
+      "items": [
+        {
+          "title": "Cert renewal re-derives expiry from the sealed certificate, not the meta.json index",
+          "body": "`b.cert`'s renewal short-circuit read `expiresAt` from the plaintext `meta.json` written beside each sealed cert. Because that index can drift from the actual certificate (or be altered independently of it), a far-future value over an actually-expiring cert would suppress renewal and serve a cert past — or about to pass — its validity. The renewal decision now parses the expiry and fingerprint from the sealed certificate itself on load, so `meta.json` is advisory only. A sealed cert that will not parse is treated as corrupt and re-issued; a corrupt `meta.json` over an otherwise-valid cert loads from the cert without a needless re-issue."
+        }
+      ]
+    },
+    {
+      "heading": "Fixed",
+      "items": [
+        {
+          "title": "Local job queue bounds the size of a payload parsed back from a stored row",
+          "body": "When the local queue leased a job or re-enqueued a repeating one, it parsed the job payload back from its stored row without an upper size bound, unlike the dead-letter listing which already capped it. A row with an oversized payload (a corrupted or tampered store) could force an unbounded parse. Both paths now cap the parse at the same 64 MiB ceiling the dead-letter path uses."
+        }
+      ]
+    }
+  ]
+}

package/lib/vendor/blamejs/release-notes/v0.13.37.json

@@ -0,0 +1,18 @@
+{
+  "$schema": "../scripts/release-notes-schema.json",
+  "version": "0.13.37",
+  "date": "2026-05-29",
+  "headline": "Encrypted-mode DB refuses writes before a full tmpfs corrupts it",
+  "summary": "In encrypted-at-rest mode the live SQLite working copy is on a tmpfs (Docker's /dev/shm defaults to 64 MiB). If that fills — an append-only audit chain and session rows grow over time — SQLite hits ENOSPC and the working copy is corrupted. Earlier releases made that corruption self-heal on the next boot by rolling back to the last encrypted snapshot, but the rollback still loses writes since the last flush. This adds the prevention side: a periodic free-space probe refuses growth writes (INSERT / UPDATE / REPLACE) with a clear db/storage-low error once free space drops below a threshold, before the tmpfs fills. DELETE and reads stay available so retention can reclaim space and the application keeps serving, and the refusal lifts automatically once free space recovers. The threshold defaults to 16 MiB of headroom and is tunable; the guard is encrypted-mode only.",
+  "sections": [
+    {
+      "heading": "Security",
+      "items": [
+        {
+          "title": "Free-space guard refuses growth writes before the tmpfs working copy fills",
+          "body": "`b.db` in encrypted-at-rest mode now probes free space on the tmpfs holding the working copy and, when it falls below `minFreeBytes` (default 16 MiB), refuses `INSERT` / `UPDATE` / `REPLACE` with a clear `db/storage-low` error instead of letting the write run the mount out of space and corrupt the database. `DELETE`, reads, and DDL stay available so retention can prune and the app keeps serving; the refusal clears automatically when free space recovers. The error message points at the cause (Docker's 64 MiB `/dev/shm` default) and the fix (`shm_size` / `--shm-size`, or pruning). Set `minFreeBytes` to tune the headroom, or `0` to disable. This complements the existing boot-time recovery: prevention (fail clear, keep recent writes) ahead of recovery (roll back to the last snapshot)."
+        }
+      ]
+    }
+  ]
+}

package/lib/vendor/blamejs/release-notes/v0.13.38.json

@@ -0,0 +1,27 @@
+{
+  "$schema": "../scripts/release-notes-schema.json",
+  "version": "0.13.38",
+  "date": "2026-05-29",
+  "headline": "Atomic cache tag invalidation, and a clusterStorage.transaction primitive for multi-statement framework writes",
+  "summary": "The cluster cache stored a value and its tag index with separate statements, so two concurrent writes to the same key could interleave their tag updates and leave the index out of step with the value — a later tag-based invalidation would then miss the key, letting a stale (possibly authorization-bearing) value survive a wipe. The value and tag writes now commit as one atomic unit. The enabling piece is a new b.clusterStorage.transaction primitive that runs a multi-statement read-modify-write all-or-nothing against the active backend — the external DB's pooled transaction in cluster mode, and a serialized transaction on the shared SQLite connection in single-node mode (so no concurrent statement can interleave into an open transaction).",
+  "sections": [
+    {
+      "heading": "Added",
+      "items": [
+        {
+          "title": "b.clusterStorage.transaction(fn) — atomic multi-statement framework-state writes",
+          "body": "Runs `fn` inside one transaction against the active backend so a multi-statement read-modify-write commits all-or-nothing. `fn` receives a transaction handle with the same `execute` / `executeOne` / `executeAll` surface, scoped to the open transaction. Cluster mode uses the external DB's pooled transaction (with its deadlock retry); single-node mode serializes against other transactions and against `execute` on the shared SQLite connection, so a concurrent statement cannot interleave into an open transaction. Use the handle's methods inside `fn` — calling the module-level `execute` from within `fn` would wait on the very transaction it is running."
+        }
+      ]
+    },
+    {
+      "heading": "Fixed",
+      "items": [
+        {
+          "title": "Cluster cache tag invalidation can no longer miss a key under concurrent writes",
+          "body": "The cluster cache wrote a value (`INSERT ... ON CONFLICT DO UPDATE`) and then rewrote its tag index (`DELETE` prior tags, `INSERT` new ones) as separate statements. Two concurrent `set()`s on the same key could interleave those tag statements, leaving the tag index inconsistent with the value — so a later `invalidateTag` could miss the key and a stale value would survive the wipe. The value and tag writes now run inside a single `clusterStorage.transaction`, so a concurrent writer observes either the whole prior state or the whole new state, never a mix."
+        }
+      ]
+    }
+  ]
+}

package/lib/vendor/blamejs/release-notes/v0.13.39.json

@@ -0,0 +1,27 @@
+{
+  "$schema": "../scripts/release-notes-schema.json",
+  "version": "0.13.39",
+  "date": "2026-05-29",
+  "headline": "Dual-control approvals are atomic — no quorum bypass or double-consume under concurrency",
+  "summary": "The dual-control approval store read a grant, mutated it in memory, and wrote it back with an await in between — a non-atomic read-modify-write. Under concurrent calls (two approvals, or a retried one) each could act on a stale snapshot: the same approver could be appended twice and reach the M-of-N quorum with a single human, or a single-use grant could be consumed twice. approve / consume / revoke / cancel now commit through a new atomic cache.update primitive, so the check and the mutation are one indivisible step. The new b.cache.update is available to application code too — the memory backend is atomic by single-thread, and the cluster backend uses a transaction with compare-and-set so a concurrent writer on another node cannot lose an update.",
+  "sections": [
+    {
+      "heading": "Security",
+      "items": [
+        {
+          "title": "Dual-control quorum and single-use guarantees hold under concurrent approvals",
+          "body": "`b.dualControl` persisted each grant through a cache read → in-memory mutate → write-back. Because the read and the write were separate awaited steps, two concurrent `approve` calls (or a retried one behind a load balancer) could each read the same pre-approval snapshot, so the duplicate-approver guard passed twice and the same approver was counted toward the M-of-N quorum twice — reaching quorum with one human. The same shape let two concurrent `consume` calls each see an unconsumed grant and both run the destructive operation. `approve` / `consume` / `revoke` / `cancel` now perform the check-and-mutate atomically via `cache.update`, so exactly one concurrent caller wins each transition."
+        }
+      ]
+    },
+    {
+      "heading": "Added",
+      "items": [
+        {
+          "title": "b.cache.update(key, mutatorFn, opts?) — atomic read-modify-write",
+          "body": "Reads the current value, calls `mutatorFn(current | null)`, and commits the result in one operation so a concurrent writer cannot clobber the change — the lost-update race that makes a plain `get` → mutate → `set` unsafe for counters, sets, and quorum state. The memory backend is atomic by single-thread; the cluster backend runs a transaction with a compare-and-set (and retries on contention) so the guarantee holds across nodes. `mutatorFn` returns `{ value }` to commit, `{ abort: data }` to leave the entry untouched and surface `data`, or `{ delete: true }` to remove it; the call resolves to `{ updated, value }`, `{ updated, deleted }`, or `{ aborted }`."
+        }
+      ]
+    }
+  ]
+}

package/lib/vendor/blamejs/release-notes/v0.13.40.json

@@ -0,0 +1,22 @@
+{
+  "$schema": "../scripts/release-notes-schema.json",
+  "version": "0.13.40",
+  "date": "2026-05-29",
+  "headline": "Redis client stops leaking a socket and blocking exit after close; DB exit-handler registers once",
+  "summary": "Two handle-lifecycle fixes. The Redis client's reconnect backoff used an untracked, non-unref'd timer: during a backoff window it alone could keep the event loop alive (a process that won't exit), and a reconnect scheduled before close() fired afterward and opened a fresh socket because the connect path didn't re-check the closing flag. The timer is now tracked, unref'd, cancelled in close(), and the connect path refuses to re-open once closing. Separately, the encrypted database registered its process-exit final-flush handler on every init(), so repeated init/close cycles (long test runs, hot reload) accumulated 'exit' listeners toward the MaxListenersExceeded warning; it now registers once for the process lifetime.",
+  "sections": [
+    {
+      "heading": "Fixed",
+      "items": [
+        {
+          "title": "Redis client cancels its reconnect timer on close and won't re-open a closed connection",
+          "body": "The reconnect backoff scheduled `setTimeout(reconnect, delay)` without keeping a handle, without `unref()`, and the reconnect path checked only `connected`/`connecting` — not `closing`. So a backoff window could by itself hold the process open (it won't exit), and a reconnect scheduled before `close()` would fire afterward and open a fresh socket with listeners — a leak after explicit close. The timer is now tracked and `unref()`'d (a backoff no longer blocks exit), cancelled in `close()`, and the connect path returns early once closing so no socket is opened after close."
+        },
+        {
+          "title": "Encrypted DB registers its process-exit flush handler once, not per init()",
+          "body": "`b.db.init()` in encrypted mode added a `process.on(\"exit\")` final-flush handler on every call. Across repeated init/close cycles — long test suites, hot reload, embedded re-inits — these accumulated and tripped Node's MaxListenersExceeded warning (and grew memory slightly). The handler is now registered once for the process lifetime, guarded by a module flag, and still flushes whichever encrypted DB is open at exit time."
+        }
+      ]
+    }
+  ]
+}

package/lib/vendor/blamejs/release-notes/v0.13.41.json

@@ -0,0 +1,27 @@
+{
+  "$schema": "../scripts/release-notes-schema.json",
+  "version": "0.13.41",
+  "date": "2026-05-29",
+  "headline": "Agent registry reads can be tenant-scoped; compliance-erasure docs clarify actor is an audit field",
+  "summary": "The agent orchestrator's registry reads (list and lookup) gated only on the flat agent-registry:read scope, so any holder could enumerate every tenant's agents and resolve a handle to one — even though the event bus already scopes subscribe and delivery by tenant. The orchestrator now mirrors that: with the new tenantScope option enabled, list returns only the actor's own tenant's agents and lookup refuses a cross-tenant name, unless the actor holds the framework cross-tenant-admin scope. Off by default, so single-tenant deployments are unaffected. Separately, the subject-erasure docs now state explicitly that the recorded actor is an audit field, not authentication — the caller must be authorized upstream.",
+  "sections": [
+    {
+      "heading": "Added",
+      "items": [
+        {
+          "title": "Tenant-scoped agent registry reads (opts.tenantScope)",
+          "body": "`b.agent.orchestrator.create({ tenantScope: true })` now scopes `list` and `lookup` to the calling actor's tenant: `list` filters out agents in other tenants and `lookup` returns null for a cross-tenant name, unless the actor holds the cross-tenant-admin scope (`b.agent.tenant.CROSS_TENANT_ADMIN_SCOPE`). This closes a cross-tenant metadata-enumeration and handle-acquisition path — `agent-registry:read` alone no longer exposes other tenants' agents — and mirrors the tenant scoping the event bus enforces on subscribe and delivery. The option defaults off; existing single-tenant orchestrators behave exactly as before. The `tenantId` argument to `list` remains a convenience filter, distinct from this authorization boundary."
+        }
+      ]
+    },
+    {
+      "heading": "Changed",
+      "items": [
+        {
+          "title": "Subject-erasure docs clarify the actor is an audit field, not authentication",
+          "body": "`b.subject.erase` and `b.subject.eraseHard` gate the deletion on operator acknowledgements and the legal-hold registry, not on caller identity. Their documentation now states explicitly that the recorded `actor` is an audit-record field, not authentication — the caller MUST be authenticated and authorized by the route before invoking. No behavior change; this removes an implicit assumption that could otherwise be read as the primitive authorizing the call."
+        }
+      ]
+    }
+  ]
+}

package/lib/vendor/blamejs/release-notes/v0.13.42.json

@@ -0,0 +1,18 @@
+{
+  "$schema": "../scripts/release-notes-schema.json",
+  "version": "0.13.42",
+  "date": "2026-05-29",
+  "headline": "S/MIME trust-chain validation binds the leaf to the key that verified the signature",
+  "summary": "When b.mail.crypto.smime.verify is given trust anchors, it validates the supplied certificate chain — but it picked the chain leaf unconditionally (the first cert) and never tied it to signerPublicKey, the key that actually verified the signature. A SignedData blob could therefore carry a validly-chained certificate for one identity while the signature was verified under an unrelated key, and the chain-validated result would imply a cert↔signer binding the code never made. Chain validation now selects the leaf as the certificate whose public key matches signerPublicKey, and refuses (signer-not-in-chain) when no certificate in the chain carries that key — so a chain-validated signature is bound to the cert it claims.",
+  "sections": [
+    {
+      "heading": "Security",
+      "items": [
+        {
+          "title": "Trust-chain leaf is bound to the verified signer key",
+          "body": "`smime.verify({ trustAnchorCertsPem })` validated the supplied chain starting from `chain[0]` without checking that the leaf's public key was the one that verified the signature (the operator-supplied `signerPublicKey`). A crafted `SignedData` could pair a validly-chained certificate for identity A with a signature verified under an unrelated key, and the chain-valid result would assert a binding that didn't hold. The chain walk now selects the leaf as the certificate whose public key equals `signerPublicKey` (matched against the certificate's SPKI, raw key or full-encoding form), and throws `mail-crypto/smime/signer-not-in-chain` when no certificate in `SignedData.certificates` carries that key. A certificate whose key cannot be extracted is treated as a non-match, so validation fails closed rather than trusting an unverifiable binding."
+        }
+      ]
+    }
+  ]
+}