@blamejs/blamejs-shop 0.2.2 → 0.2.3

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.2.x
 
+- v0.2.3 (2026-05-27) — **Admin console adopts the dark violet brand — the operator dashboard now matches the storefront.** The admin console has been restyled from its previous light theme and orange accent onto the same dark violet identity as the storefront: a neutral near-black canvas with violet reserved for accents, the self-hosted Hanken Grotesk and Space Mono typefaces in place of Inter, and Space Mono carrying the terminal-style chrome (header mark, navigation, micro-labels, figures, SKUs, order ids, and code). Stat cards, tables, status pills, forms, buttons, banners, nav cards, and the sign-in card are all recoloured for the dark surface with contrast preserved — order statuses keep their meaning (green for paid/shipped, amber for pending, violet for refunded, muted for cancelled), form inputs read clearly on the dark wells, and the revenue sparkline is drawn in the brand violet. Operators on the default theme get the new console on upgrade; no admin functionality, routes, or data change. **Changed:** *Dark violet admin theme* — The admin stylesheet is rebuilt on the storefront's palette — near-black surfaces, neutral hairline borders, and violet reserved for accents (active nav, primary buttons, the `/ admin` mark, focus states, and the revenue sparkline) rather than the former light paper and orange. Self-hosted Hanken Grotesk (display/body) and Space Mono (chrome/mono) replace Inter, loaded under the strict `font-src 'self'` policy. · *Components recoloured for the dark surface* — Stat cards, the orders table, status pills, filter chips, forms, buttons (primary/ghost/danger), banners, nav cards, the gift-card detail grid, and the sign-in card are all restyled for dark with contrast maintained. Order-status pills keep their semantics — green for paid/shipped/fulfilling/delivered, amber for pending, violet for refunded, muted for cancelled. Form inputs sit on recessed dark wells with light text and a violet focus ring.
+
 - v0.2.2 (2026-05-27) — **Bespoke line-art illustrations across the storefront — category tiles, image placeholders, and every empty state.** The storefront's stand-in graphics are now a single, cohesive set of hand-drawn line illustrations in the brand violet, replacing the previous mix of gradient-only tiles, single-letter image marks, and emoji. The six featured-collection tiles carry a matching icon (apparel, hardware, digital, subscriptions, bundles, gift cards). Products without an image — in the grid and on the product page — show a bespoke "no image yet" placeholder instead of a letter glyph. Every empty state has its own illustration: cart, search, wishlist, saved-for-later, addresses, returns, and orders. The artwork is inline SVG (no extra files fetched, consistent with the strict asset policy) and adapts to the surface — the fine detail strokes follow the text colour, so the same set reads correctly on a dark or a light background. **Changed:** *Category tiles carry line-art icons* — Each of the six featured-collection tiles now shows a violet line icon for its category, centered over the existing tile gradient. The tile links and labels are unchanged. · *Bespoke image placeholder replaces the letter mark* — When a product has no image, the grid card and the product-page gallery render a line-art "no image yet" placeholder — an isometric package on a faint grid (the product page adds a shield motif and a terminal-prompt accent) — instead of the previous single uppercase letter. The no-image grid card now uses the same media-card layout as image-bearing cards for a consistent grid. · *Every empty state has matching artwork* — The empty cart, no-search-results, empty wishlist, saved-for-later, addresses, returns, and orders states now show a bespoke line illustration in place of the previous emoji or unicode glyphs, so the storefront and account sections share one visual language. · *Inline, theme-adaptive SVG* — All of the new artwork is inline SVG with presentation attributes only — nothing is fetched from a CDN and no inline styles are used, consistent with the strict content-security and asset policies. The detail strokes use currentColor, so the set adapts to the background it sits on. The edge and container renderers emit identical markup.
 
 - v0.2.1 (2026-05-27) — **Theme tuning — stronger contrast, a cleaner product buy-box, and natural code-sample colors.** A polish pass over the new dark theme. The palette is rebalanced so the brand violet reads as a deliberate accent rather than the whole field: surfaces, borders, and shadows are now neutral dark, body text and prices are high-contrast near-white, and violet is concentrated on calls-to-action, the hero accent, and the newsletter band. The product page's buy-box is now a single contained card — price, variant, quantity, and add-to-cart group cleanly with proper spacing and alignment instead of blending into the column, and the wishlist/compare controls sit in their own separated row. The homepage code sample uses natural syntax-highlight colours (green strings, blue functions, violet keywords) with the usual window dots. The home collection tiles are calmer dark tiles with a subtle violet glow rather than solid magenta swatches. **Changed:** *Rebalanced palette for contrast* — Surfaces (`--surface`, card and raised tiers) and borders are now neutral dark instead of violet-tinted; secondary text and prices are high-contrast near-white; default shadows are neutral. The violet accent is reserved for primary buttons, the hero accent word, focus states, and the newsletter/framework bands — so contrast and hierarchy are clearer and the page no longer reads as a single wash of magenta. · *Product buy-box is a contained, aligned card* — Price, variant chip(s), quantity, and the full-width add-to-cart now sit in one bordered buy-box card with consistent spacing, the price rendered in high-contrast white, and the post-quantum-secured-checkout trust line as a calm note beneath it. The wishlist and compare controls are grouped into their own row, separated from the buy-box. No change to add-to-cart, variant, or currency behaviour. · *Natural code-sample colours and calmer collection tiles* — The homepage server-rendered code sample now uses a natural console palette — green strings, blue function names, violet keywords, grey comments — with red/yellow/green window dots. The home collection tiles are dark with a subtle, position-varied violet glow instead of solid violet gradient fills.

package/lib/admin.js

@@ -2586,9 +2586,9 @@ function mount(router, deps) {
 //
 // Server-rendered HTML dashboard for `GET /admin/dashboard`. Reads
 // the four analytics aggregates and lays them out in a single page
-// matching the storefront's brand palette (#191919 ink, #fa4f09
-// accent, Montserrat headlines). No client-side JS — the SVG sparkline
-// is rendered server-side from the revenue-by-day rows.
+// matching the storefront's dark violet brand (near-black canvas,
+// #AD38DB accent, Hanken Grotesk + Space Mono). No client-side JS —
+// the SVG sparkline is rendered server-side from the revenue-by-day rows.
 
 var DASHBOARD_LAYOUT =
   "<!DOCTYPE html>\n" +
@@ -2648,7 +2648,7 @@ function _sparkSvg(byDay, currency) {
     return (i === 0 ? "M" : "L") + x.toFixed(1) + "," + y.toFixed(1);
   }).join(" ");
   return "<div class=\"spark\"><svg viewBox=\"0 0 " + W + " " + H + "\" preserveAspectRatio=\"none\" aria-label=\"Revenue by day sparkline\">" +
-         "<path d=\"" + path + "\" fill=\"none\" stroke=\"#fa4f09\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"/>" +
+         "<path d=\"" + path + "\" fill=\"none\" stroke=\"#AD38DB\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\"/>" +
          "</svg></div>";
 }
 

package/lib/asset-manifest.json

@@ -1,9 +1,9 @@
 {
-  "version": "0.2.2",
+  "version": "0.2.3",
   "assets": {
     "css/admin.css": {
-      "integrity": "sha384-oUi6NkXA0ULSy8+8+LG0FV6jsgr7Y11Xf3VdnwUESnvUPaN7anYEC+QOAUXwgsap",
-      "fingerprinted": "css/admin.7b692a8965624a0c.css"
+      "integrity": "sha384-FgqvXcZygYkJjjOtXAeu9xi6AtYqkchPnJKcS0OeHm8lynhd9r4RfdpoT7P7j7/l",
+      "fingerprinted": "css/admin.afd7b964c1f6fe1b.css"
     },
     "css/main.css": {
       "integrity": "sha384-iKbkn3AR4k733EgN+1Ju51qbKfz9yVmDk8lE2l99asnRGbSo4BJu4Lo+OTxcBME4",

package/lib/vendor/MANIFEST.json

@@ -3,8 +3,8 @@
   "_about": "blamejs.shop vendors a single framework — blamejs — which itself bundles every server-side crypto/identity dependency. The transitive packages blamejs ships are surfaced in its own MANIFEST.json at lib/vendor/blamejs/lib/vendor/MANIFEST.json — Trivy / Grype rely on that nested data for CVE attribution.",
   "packages": {
     "blamejs": {
-      "version": "0.13.13",
-      "tag": "v0.13.13",
+      "version": "0.13.14",
+      "tag": "v0.13.14",
       "license": "Apache-2.0",
       "author": "blamejs contributors",
       "source": "https://github.com/blamejs/blamejs",

package/lib/vendor/blamejs/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.13.x
 
+- v0.13.14 (2026-05-27) — **DNSSEC chain validation now bounds KeyTrap (CVE-2023-50387) amplification with hard caps.** b.network.dns.dnssec.verifyChain tried every DNSKEY whose 16-bit key tag matched an RRSIG, with no cap on how many candidates or total signature verifications a single response could drive. A hostile zone publishing many DNSKEYs sharing one key tag (plus matching RRSIGs) could force O(keys x signatures) full public-key verifications from one query — the KeyTrap denial-of-service (CVE-2023-50387). Validation is now bounded by non-configurable caps that match the BIND / Unbound mitigations: at most 4 same-tag candidate keys are tried per RRSIG, at most 64 DNSKEYs per zone link and 16 DS records per delegation are accepted, the chain is at most 128 links deep, and the whole response is held to a signature-validation budget that scales with chain depth (so a legitimate deep delegation is never false-rejected while bounded collisions stay bounded); exceeding any of these refuses the response rather than performing the work. Separately, a domain name that encodes to more than 255 octets is now refused at canonicalization (RFC 1035 §2.3.4), which also bounds the NSEC3 closest-encloser label enumeration, and the NSEC3 iteration ceiling is lowered from 500 to 150 to match the BIND 9.16.33+ / Unbound 1.17.1 fix for the sibling CVE-2023-50868. **Security:** *`verifyChain` caps colliding-key fan-out and total signature validations (KeyTrap / CVE-2023-50387)* — A zone advertising many same-key-tag DNSKEYs and RRSIGs can no longer drive unbounded public-key verifications. New refusals: `dnssec/too-many-colliding-keys` (>4 same-tag candidates per RRSIG), `dnssec/too-many-dnskeys` (>64 DNSKEYs per zone link), `dnssec/too-many-ds` (>16 DS records per delegation), `dnssec/too-many-links` (chain deeper than 128), and `dnssec/validation-budget-exceeded` (signature validations beyond the depth-scaled budget). The caps are intentionally non-configurable — they sit well above any legitimate zone, and the budget scales with chain depth so deep delegations validate normally. · *Domain-name octet cap + lower NSEC3 iteration ceiling* — A name that canonicalizes to more than 255 octets is refused (`dnssec/bad-name`, RFC 1035 §2.3.4), which bounds the per-label NSEC3 closest-encloser enumeration (CVE-2023-50868 class). The default NSEC3 iteration ceiling drops from 500 to 150, matching the BIND 9.16.33+ / Unbound 1.17.1 post-CVE defaults (RFC 9276 recommends 0).
+
 - v0.13.13 (2026-05-27) — **Archive extraction-path verification now refuses Windows reserved names, NTFS data streams, and trailing-dot/space per segment.** b.guardFilename.verifyExtractionPath (the per-entry gate b.archive.read.zip.extract / b.safeArchive run on every extracted file) checked traversal, absolute paths, drive-letter and UNC prefixes, null bytes, PATH_MAX overflow, and realpath containment — but not the per-segment Windows write-target hazards the disk validate / sanitize paths already reject. An archive entry named CON, NUL.txt, subdir/LPT1, file.txt:hidden, or secret.txt. stayed inside the extraction root, so the containment and realpath checks passed it, yet on Windows it would resolve to a device, write a hidden NTFS stream, or (after Windows strips the trailing dot/space) overwrite a sibling file. These are now refused: any path segment that collides with a Windows reserved device name, uses NTFS alternate-data-stream syntax (name:stream), or carries a trailing dot or leading/trailing whitespace. The checks are platform-unconditional — a verifier running on Linux still refuses names that are only dangerous on the Windows host that ultimately extracts the archive — with a per-check opt-out (reservedNamePolicy / adsPolicy / leadingTrailingPolicy: "allow") for Linux-only targets. **Security:** *`verifyExtractionPath` refuses per-segment Windows extraction hazards (reserved names / NTFS ADS / trailing dot-space)* — Closes a within-root write-target-redirection gap: an extracted entry could stay inside the destination yet, on Windows, resolve to a device (`CON` / `NUL` / `COM1` / `LPT1`), write a hidden alternate data stream (`file.txt:payload`), or overwrite a sibling after Windows strips a trailing dot/space (`config.`). The verification gate now rejects all three per path segment. Refusal is platform-unconditional (the verifier may run on a different OS than the extractor); set `reservedNamePolicy` / `adsPolicy` / `leadingTrailingPolicy` to `"allow"` to opt a check out on a Linux-only target. Single-entry, name-only residuals — 8.3 short-name aliasing, case-insensitive cross-entry collisions, and archive symlink/hardlink entry-target validation — remain the extract orchestrator's responsibility (it owns the case-folded seen-set and the link-target gate).
 
 - v0.13.12 (2026-05-27) — **Inbound MX listener now runs the connection-level gate cascade it documented — HELO identity, DNS blocklist, and greylisting.** b.mail.server.mx.create documented helo / rbl / greylist gate options, but the listener never invoked them — an operator who wired them got silent acceptance of mail those gates would have rejected. They are now wired into the live SMTP state machine: the HELO-identity gate evaluates at HELO/EHLO and refuses a spoofed or malformed identity with 550; the DNS-blocklist gate evaluates the connecting IP once per connection and refuses a listed source with 554; the greylisting gate defers a first-seen (ip, sender, recipient) tuple with a 450 tempfail so legitimate senders retry and pass. Each gate is skipped when the operator doesn't wire it. Because these gates do DNS and store lookups, the per-connection command pump was reworked to process commands asynchronously and strictly in arrival order, so pipelined commands (RFC 2920) cannot overtake a gate still resolving and the existing SMTP-smuggling and STARTTLS-stripping defenses are unchanged. The message-authentication gate (SPF/DKIM/DMARC alignment via b.guardEnvelope) needs the inbound SPF + DKIM verification results as inputs; that inbound-auth pipeline lands as a follow-up, and the documentation no longer implies that gate is active today. **Added:** *HELO-identity / RBL / greylist gates wired into `b.mail.server.mx`* — When wired, `opts.helo` (FCrDNS / HELO-shape / self-name checks) refuses a bad HELO identity at HELO/EHLO with 550; `opts.rbl` refuses a connecting IP found on a DNS blocklist with 554 (evaluated once per connection); `opts.greylist` defers a first-seen (ip, sender, recipient) tuple with 450 4.7.1. Their verdicts surface on the `rcpt_to` event (`rblListed`, `greylist`) and the `helo` event (`heloVerdict`), with dedicated `helo_gate_refused` / `rbl_refused` / `greylist_deferred` audit events. A gate the operator doesn't supply is skipped, never synthesized. **Changed:** *MX command pump processes commands asynchronously and in arrival order* — Gate evaluation involves DNS and store lookups, so the per-connection command pump now awaits each command before the next. Pipelined commands are serialized so a gate resolving cannot let a later command answer ahead of an earlier one; reply ordering, the bare-LF SMTP-smuggling refusal, and the STARTTLS-stripping defense are unchanged. No change to the listener's external behaviour when no gates are wired. **Deprecated:** *SPF/DKIM/DMARC-alignment gate documentation corrected to match what is active* — The `envelope` (SPF/DKIM/DMARC alignment) and `dmarc` gate options were documented as wireable but require inbound SPF + DKIM verification results the listener does not yet produce. They are removed from the documented option set until the inbound-authentication pipeline (composing `b.mail.spf` + `b.mail.dmarc` + DKIM verification) lands; run those checks on the delivered message via the agent handoff in the meantime.

package/lib/vendor/blamejs/SECURITY.md

@@ -352,7 +352,7 @@ This is the minimum-viable security posture for a production deployment. The fra
 - [ ] At boot, before any outbound socket opens: call `b.network.bootFromEnv({ env: process.env, audit: b.audit })` so operator-supplied NTP / DNS / proxy / DPI-trust / TCP socket settings (`BLAMEJS_NTP_*`, `BLAMEJS_DNS_*`, `HTTP_PROXY` / `HTTPS_PROXY` / `NO_PROXY`, `BLAMEJS_EXTRA_CA_CERTS`, `BLAMEJS_SOCKET_*`) apply uniformly
 - [ ] If the deployment sits behind a deep-packet-inspection proxy with its own re-signing CA: install the CA via `b.network.tls.addCa("/path/to/corp-ca.pem", { label: "corp-mitm" })` and pass `allowDpiTrust: true` to `b.security.assertProduction` — every CA addition audits with subject + fingerprint so a forensic review can reconstruct the trust path
 - [ ] For authenticated time (HIPAA / PCI / FIPS shops): use `b.network.ntp.nts.query({ host: ntsKeServer })` (RFC 8915) instead of plain SNTP; set `BLAMEJS_NTS_REQUIRE=1` to fail closed on negotiation failure
-- [ ] When a DNS answer drives a trust decision (DANE / TLSA pinning, SSHFP, CAA enforcement, OPENPGPKEY lookup) and the upstream resolver isn't itself trusted: verify the answer's DNSSEC signature with `b.network.dns.dnssec.verifyRrset(...)` rather than trusting the resolver's AD bit — an on-path or compromised resolver can set AD on a forged answer, but cannot forge the RRSIG. Validate the whole delegation chain root→TLD→zone with `b.network.dns.dnssec.verifyChain(...)` (default-pinned to the IANA root KSKs, or `trustAnchors` for a private root) so trust is anchored, not borrowed from the resolver. For a negative answer that drives a fail-closed decision (an allowlist lookup, a revocation check), verify the NSEC / NSEC3 proof with `b.network.dns.dnssec.verifyDenial(...)` so a forged NXDOMAIN cannot suppress a record; keep the default Opt-Out refusal unless the zone's opt-out spans are acceptable for that decision. For DANE / TLSA, once the TLSA RRset is DNSSEC-verified, pin the peer certificate with `b.network.dns.dane.matchCertificate(...)` — a DANE-EE(3) match authenticates the key with no public CA, while PKIX usages are flagged as still needing PKIX
+- [ ] When a DNS answer drives a trust decision (DANE / TLSA pinning, SSHFP, CAA enforcement, OPENPGPKEY lookup) and the upstream resolver isn't itself trusted: verify the answer's DNSSEC signature with `b.network.dns.dnssec.verifyRrset(...)` rather than trusting the resolver's AD bit — an on-path or compromised resolver can set AD on a forged answer, but cannot forge the RRSIG. Validate the whole delegation chain root→TLD→zone with `b.network.dns.dnssec.verifyChain(...)` (default-pinned to the IANA root KSKs, or `trustAnchors` for a private root) so trust is anchored, not borrowed from the resolver. `verifyChain` bounds KeyTrap (CVE-2023-50387) amplification with non-configurable caps (≤4 same-tag candidate keys per RRSIG, ≤64 DNSKEYs/zone, ≤16 DS/delegation, ≤128 chain links, and a signature-validation budget that scales with chain depth so deep delegations validate while bounded collisions stay bounded) and caps NSEC3 iterations at 150 (CVE-2023-50868) — a hostile zone is refused, not allowed to exhaust CPU. For a negative answer that drives a fail-closed decision (an allowlist lookup, a revocation check), verify the NSEC / NSEC3 proof with `b.network.dns.dnssec.verifyDenial(...)` so a forged NXDOMAIN cannot suppress a record; keep the default Opt-Out refusal unless the zone's opt-out spans are acceptable for that decision. For DANE / TLSA, once the TLSA RRset is DNSSEC-verified, pin the peer certificate with `b.network.dns.dane.matchCertificate(...)` — a DANE-EE(3) match authenticates the key with no public CA, while PKIX usages are flagged as still needing PKIX
 - [ ] At boot in production: call `await b.security.assertProduction({ vault: "wrapped", dbAtRest: "encrypted", auditSigning: "wrapped", ntpStrict: true, requireEnv: ["BLAMEJS_VAULT_PASSPHRASE"], dataDir: "./data" })` to refuse to start on weak posture instead of warning
 - [ ] At boot: call `await b.configDrift.create({ dataDir, audit }).checkpoint({ allowedOrigins, csp, vaultMode, ... })` so the next boot detects + audits any silent runtime config change
 - [ ] At boot, before any listener opens: call `b.configDrift.verifyVendorIntegrity({ manifestPath: "./lib/vendor/MANIFEST.json", audit: b.audit })` so a tampered `lib/vendor/*.cjs` artifact aborts start instead of running with a swapped crypto bundle

package/lib/vendor/blamejs/api-snapshot.json

@@ -1,7 +1,7 @@
 {
   "version": 1,
-  "frameworkVersion": "0.13.13",
-  "createdAt": "2026-05-27T11:10:37.499Z",
+  "frameworkVersion": "0.13.14",
+  "createdAt": "2026-05-27T12:40:36.809Z",
   "exports": {
     "a2a": {
       "type": "object",

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

@@ -101,7 +101,16 @@ function _canonicalName(name) {
     parts.push(Buffer.from([lab.length]), lab);
   }
   parts.push(Buffer.from([0]));
-  return Buffer.concat(parts);
+  var wire = Buffer.concat(parts);
+  // RFC 1035 §2.3.4 — a domain name is at most 255 octets on the wire.
+  // Enforcing it here also bounds the per-label count (and thus the NSEC3
+  // closest-encloser candidate enumeration, CVE-2023-50868 class), since
+  // each label costs at least 2 octets.
+  if (wire.length > 255) {                                                               // allow:raw-byte-literal — RFC 1035 total-name octet cap
+    throw new DnssecError("dnssec/bad-name",
+      "dnssec: name '" + name + "' encodes to " + wire.length + " octets, exceeds RFC 1035 cap of 255");
+  }
+  return wire;
 }
 
 function _u16(n) { return Buffer.from([(n >> 8) & 0xff, n & 0xff]); }                    // allow:raw-byte-literal — 16-bit big-endian split
@@ -340,7 +349,28 @@ var BASE32HEX = "0123456789ABCDEFGHIJKLMNOPQRSTUV";          // allow:raw-byte-l
 var TYPE_DS = 43;                                            // allow:raw-byte-literal — IANA RR type DS
 var TYPE_CNAME = 5;
 var NSEC3_HASH_SHA1 = 1;                                     // RFC 5155 §5 — the only registered NSEC3 hash
-var DEFAULT_MAX_NSEC3_ITERATIONS = 500;                      // allow:raw-time-literal — DoS ceiling on iterated SHA-1 (RFC 9276 wants 0; deployed zones still use >0)
+var DEFAULT_MAX_NSEC3_ITERATIONS = 150;                      // allow:raw-time-literal — DoS ceiling on iterated SHA-1; matches BIND 9.16.33+/Unbound 1.17.1 post-CVE-2023-50868 (RFC 9276 wants 0; deployed zones still use >0)
+
+// KeyTrap (CVE-2023-50387) amplification caps. A hostile zone can publish
+// many DNSKEYs sharing one 16-bit key tag and many RRSIGs, forcing a
+// validator into O(keys x sigs) full signature verifications from a single
+// query. Bound both factors: the colliding-candidate fan-out per RRSIG, and
+// the total signature-validation work. Matches the BIND
+// `max-key-tag-collisions` + Unbound validation-budget mitigations.
+//
+// The per-response budget SCALES with declared chain depth so a legitimate
+// deep delegation isn't false-rejected: a valid N-link chain does ~2N-1
+// signature verifies (1 root DNSKEY + parent-DS + child-DNSKEY per child),
+// so the budget is links.length * MAX_VALIDATIONS_PER_LINK (= 2 RRSIGs/link
+// x MAX_COLLIDING_KEYS candidates), which always covers the legitimate work
+// while still bounding the bounded-collision amplification. Chain length
+// itself is capped (a delegation can't be deeper than a DNS name's label
+// count, RFC 1035), so the scaled budget can't be inflated arbitrarily.
+var MAX_COLLIDING_KEYS       = 4;                            // allow:raw-byte-literal — same-tag DNSKEY candidates tried per RRSIG
+var MAX_VALIDATIONS_PER_LINK = 8;                            // allow:raw-byte-literal — 2 RRSIGs/link x MAX_COLLIDING_KEYS; budget = links.length x this
+var MAX_CHAIN_LINKS          = 128;                          // allow:raw-byte-literal — max delegation depth (>= RFC 1035 max label count)
+var MAX_DNSKEYS_PER_ZONE     = 64;                           // allow:raw-byte-literal — DNSKEY RRset size cap per zone link
+var MAX_DS_RECORDS           = 16;                           // allow:raw-byte-literal — DS RRset size cap (parent-supplied)
 
 // RFC 4648 §7 base32hex decode (no padding, case-insensitive) — the
 // label encoding of an NSEC3 owner-name hash.
@@ -757,12 +787,31 @@ function _keysByTag(dnskeys, tag) {
 // returning the key that validated. A wrong colliding key yields
 // `dnssec/bad-signature` — that is not terminal, the next candidate is
 // tried; any other error (expired, alg) is terminal. RFC 4035 §5.3.1.
-function _verifyRrsetWithAnyKey(rrsetBase, rrsig, candidates, noKeyCode, noKeyMsg) {
+function _verifyRrsetWithAnyKey(rrsetBase, rrsig, candidates, noKeyCode, noKeyMsg, budget) {
   if (candidates.length === 0) throw new DnssecError(noKeyCode, noKeyMsg);
+  // KeyTrap (CVE-2023-50387): refuse an absurd same-tag fan-out outright —
+  // legitimate zones have 1-2 keys per tag; hundreds is an amplification
+  // attack, not a real collision.
+  if (candidates.length > MAX_COLLIDING_KEYS) {
+    throw new DnssecError("dnssec/too-many-colliding-keys",
+      "dnssec.verifyChain: " + candidates.length + " DNSKEYs share key tag " +
+      rrsig.keyTag + " (cap " + MAX_COLLIDING_KEYS +
+      ") — refused as a KeyTrap (CVE-2023-50387) amplification vector");
+  }
   var lastErr = null;
   for (var i = 0; i < candidates.length; i++) {
     var kp = _dnskeyParts(candidates[i]);
     if (kp.algorithm !== rrsig.algorithm) { lastErr = new DnssecError("dnssec/alg-mismatch", "dnssec.verifyChain: candidate key algorithm does not match the RRSIG"); continue; }
+    // Per-response signature-validation budget — bound the total expensive
+    // pubkey verifies across the whole chain walk, not just per RRSIG.
+    if (budget) {
+      if (budget.remaining <= 0) {
+        throw new DnssecError("dnssec/validation-budget-exceeded",
+          "dnssec.verifyChain: per-response signature-validation budget " +
+          "exhausted — refused as a KeyTrap (CVE-2023-50387) amplification vector");
+      }
+      budget.remaining -= 1;
+    }
     try {
       verifyRrset(Object.assign({}, rrsetBase, { rrsig: rrsig, dnskey: { algorithm: kp.algorithm, publicKey: kp.publicKey } }));
       return candidates[i];
@@ -795,6 +844,20 @@ function _verifyRrsetWithAnyKey(rrsetBase, rrsig, candidates, noKeyCode, noKeyMs
  * passes to <code>verifyRrset</code> / <code>verifyDenial</code> for the
  * actual answer.
  *
+ * KeyTrap (CVE-2023-50387) amplification is bounded with non-configurable
+ * caps: at most 4 same-tag DNSKEY candidates are tried per RRSIG, at most
+ * 64 DNSKEYs per zone link and 16 DS records per delegation are accepted,
+ * the chain is at most 128 links deep, and the whole response is held to a
+ * signature-validation budget that scales with chain depth (so a
+ * legitimate deep delegation always fits while bounded collisions stay
+ * bounded). A hostile zone publishing many colliding keys / signatures is
+ * refused with <code>dnssec/too-many-colliding-keys</code> /
+ * <code>dnssec/too-many-dnskeys</code> / <code>dnssec/too-many-ds</code> /
+ * <code>dnssec/too-many-links</code> /
+ * <code>dnssec/validation-budget-exceeded</code> rather than driving
+ * O(keys x sigs) verifications. (NSEC3 iteration counts are separately
+ * capped at 150 per RFC 9276 / the CVE-2023-50868 fix.)
+ *
  * @opts
  *   {
  *     links: [ {                        // ordered root-first
@@ -816,14 +879,35 @@ function verifyChain(opts) {
   validateOpts.requireObject(opts, "dnssec.verifyChain", DnssecError);
   validateOpts(opts, ["links", "trustAnchors", "at"], "dnssec.verifyChain");
   if (!Array.isArray(opts.links) || opts.links.length === 0) throw new DnssecError("dnssec/bad-arg", "dnssec.verifyChain: opts.links must be a non-empty array");
+  // Cap delegation depth — a real chain can't be deeper than a DNS name's
+  // label count (RFC 1035), and the per-response validation budget below
+  // scales with this, so it must be bounded.
+  if (opts.links.length > MAX_CHAIN_LINKS) {
+    throw new DnssecError("dnssec/too-many-links",
+      "dnssec.verifyChain: " + opts.links.length + " chain links (cap " +
+      MAX_CHAIN_LINKS + ") — refused as an amplification vector");
+  }
   var anchors = opts.trustAnchors !== undefined ? opts.trustAnchors : DEFAULT_ROOT_ANCHORS;
   if (!Array.isArray(anchors) || anchors.length === 0) throw new DnssecError("dnssec/bad-arg", "dnssec.verifyChain: opts.trustAnchors must be a non-empty array");
 
+  // KeyTrap budget shared across every signature-validation in this
+  // response, scaled to the declared chain depth so a legitimate deep
+  // delegation (2N-1 verifies) always fits while bounded collisions stay
+  // bounded. Chain length is capped above, so this can't be inflated.
+  var budget = { remaining: opts.links.length * MAX_VALIDATIONS_PER_LINK };
+
   var trustedKeys = null, path = [];
   for (var i = 0; i < opts.links.length; i++) {
     var link = opts.links[i];
     if (!link || typeof link.zone !== "string" || link.zone === "") throw new DnssecError("dnssec/bad-link", "dnssec.verifyChain: links[" + i + "].zone is required");
     if (!Array.isArray(link.dnskeys) || link.dnskeys.length === 0) throw new DnssecError("dnssec/bad-link", "dnssec.verifyChain: links[" + i + "].dnskeys must be a non-empty array");
+    // KeyTrap: bound the DNSKEY RRset size per zone so a giant key set
+    // can't blow up the key-tag scan / candidate fan-out.
+    if (link.dnskeys.length > MAX_DNSKEYS_PER_ZONE) {
+      throw new DnssecError("dnssec/too-many-dnskeys",
+        "dnssec.verifyChain: links[" + i + "] has " + link.dnskeys.length +
+        " DNSKEYs (cap " + MAX_DNSKEYS_PER_ZONE + ") — refused as a KeyTrap (CVE-2023-50387) amplification vector");
+    }
     if (!link.dnskeyRrsig || typeof link.dnskeyRrsig !== "object") throw new DnssecError("dnssec/bad-link", "dnssec.verifyChain: links[" + i + "].dnskeyRrsig is required");
 
     // 1. The DNSKEY RRset is self-signed by one of its own keys (trying
@@ -832,7 +916,8 @@ function verifyChain(opts) {
       { name: link.zone, type: "DNSKEY", rdatas: link.dnskeys, at: opts.at },
       link.dnskeyRrsig,
       _keysByTag(link.dnskeys, link.dnskeyRrsig.keyTag),
-      "dnssec/chain-no-signing-key", "dnssec.verifyChain: no DNSKEY in '" + link.zone + "' verifies the DNSKEY RRSIG"
+      "dnssec/chain-no-signing-key", "dnssec.verifyChain: no DNSKEY in '" + link.zone + "' verifies the DNSKEY RRSIG",
+      budget
     );
 
     // 2. Establish trust in the signing key.
@@ -851,11 +936,19 @@ function verifyChain(opts) {
       if (!Array.isArray(link.dsRdatas) || link.dsRdatas.length === 0 || !link.dsRrsig || typeof link.dsRrsig !== "object") {
         throw new DnssecError("dnssec/bad-link", "dnssec.verifyChain: links[" + i + "] needs dsRdatas + dsRrsig (DS served by the parent)");
       }
+      // Bound the parent-supplied DS RRset — the DS-match loop below
+      // iterates it, and an oversize set is an amplification vector.
+      if (link.dsRdatas.length > MAX_DS_RECORDS) {
+        throw new DnssecError("dnssec/too-many-ds",
+          "dnssec.verifyChain: links[" + i + "] has " + link.dsRdatas.length +
+          " DS records (cap " + MAX_DS_RECORDS + ") — refused as an amplification vector");
+      }
       _verifyRrsetWithAnyKey(
         { name: link.zone, type: "DS", rdatas: link.dsRdatas, at: opts.at },
         link.dsRrsig,
         _keysByTag(trustedKeys, link.dsRrsig.keyTag),
-        "dnssec/chain-no-parent-key", "dnssec.verifyChain: no trusted parent key verifies the DS RRSIG for '" + link.zone + "'"
+        "dnssec/chain-no-parent-key", "dnssec.verifyChain: no trusted parent key verifies the DS RRSIG for '" + link.zone + "'",
+        budget
       );
       var dsMatched = false;
       for (var d = 0; d < link.dsRdatas.length; d++) {

package/lib/vendor/blamejs/lib/parsers/safe-toml.js

@@ -681,6 +681,14 @@ function parse(input, opts) {
               "toml/redefine");
           }
           t = sub[sub.length - 1];
+          // The array's last element must itself be a table to descend
+          // into. A plain VALUE array (e.g. `a = [3]` then `[a.s]`) has a
+          // scalar last element — descending would set a property on a
+          // number and throw a raw TypeError; refuse it cleanly instead.
+          if (t === null || typeof t !== "object" || Array.isArray(t)) {
+            throw _err("cannot descend into '" + seg +
+              "' — it is a value array, not an array of tables", "toml/redefine");
+          }
           continue;
         }
         if (typeof sub !== "object" || sub === null) {

package/lib/vendor/blamejs/package.json

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

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

@@ -0,0 +1,22 @@
+{
+  "$schema": "../scripts/release-notes-schema.json",
+  "version": "0.13.14",
+  "date": "2026-05-27",
+  "headline": "DNSSEC chain validation now bounds KeyTrap (CVE-2023-50387) amplification with hard caps",
+  "summary": "b.network.dns.dnssec.verifyChain tried every DNSKEY whose 16-bit key tag matched an RRSIG, with no cap on how many candidates or total signature verifications a single response could drive. A hostile zone publishing many DNSKEYs sharing one key tag (plus matching RRSIGs) could force O(keys x signatures) full public-key verifications from one query — the KeyTrap denial-of-service (CVE-2023-50387). Validation is now bounded by non-configurable caps that match the BIND / Unbound mitigations: at most 4 same-tag candidate keys are tried per RRSIG, at most 64 DNSKEYs per zone link and 16 DS records per delegation are accepted, the chain is at most 128 links deep, and the whole response is held to a signature-validation budget that scales with chain depth (so a legitimate deep delegation is never false-rejected while bounded collisions stay bounded); exceeding any of these refuses the response rather than performing the work. Separately, a domain name that encodes to more than 255 octets is now refused at canonicalization (RFC 1035 §2.3.4), which also bounds the NSEC3 closest-encloser label enumeration, and the NSEC3 iteration ceiling is lowered from 500 to 150 to match the BIND 9.16.33+ / Unbound 1.17.1 fix for the sibling CVE-2023-50868.",
+  "sections": [
+    {
+      "heading": "Security",
+      "items": [
+        {
+          "title": "`verifyChain` caps colliding-key fan-out and total signature validations (KeyTrap / CVE-2023-50387)",
+          "body": "A zone advertising many same-key-tag DNSKEYs and RRSIGs can no longer drive unbounded public-key verifications. New refusals: `dnssec/too-many-colliding-keys` (>4 same-tag candidates per RRSIG), `dnssec/too-many-dnskeys` (>64 DNSKEYs per zone link), `dnssec/too-many-ds` (>16 DS records per delegation), `dnssec/too-many-links` (chain deeper than 128), and `dnssec/validation-budget-exceeded` (signature validations beyond the depth-scaled budget). The caps are intentionally non-configurable — they sit well above any legitimate zone, and the budget scales with chain depth so deep delegations validate normally."
+        },
+        {
+          "title": "Domain-name octet cap + lower NSEC3 iteration ceiling",
+          "body": "A name that canonicalizes to more than 255 octets is refused (`dnssec/bad-name`, RFC 1035 §2.3.4), which bounds the per-label NSEC3 closest-encloser enumeration (CVE-2023-50868 class). The default NSEC3 iteration ceiling drops from 500 to 150, matching the BIND 9.16.33+ / Unbound 1.17.1 post-CVE defaults (RFC 9276 recommends 0)."
+        }
+      ]
+    }
+  ]
+}

package/lib/vendor/blamejs/test/00-primitives.js

@@ -13545,6 +13545,15 @@ function testTomlSecurityRejections() {
   catch (e) { threwRedefine = e.code === "toml/redefine"; }
   check("toml: table redefinition rejected",       threwRedefine);
 
+  // Table header descending through a VALUE array (not an array-of-tables)
+  // — `a = [3]` then `[a.s]` walks into the array's scalar element. A fuzz
+  // input hit this; it must refuse cleanly, not throw a raw TypeError.
+  var threwValueArrayDescend = null;
+  try { b.parsers.toml.parse("a = [3]\n[a.s]\n"); }
+  catch (e) { threwValueArrayDescend = e.code; }
+  check("toml: table header descending into a value array rejected cleanly",
+        threwValueArrayDescend === "toml/redefine");
+
   // Size cap
   var threwSize = false;
   try { b.parsers.toml.parse("a = \"" + "x".repeat(2000) + "\"", { maxBytes: 1000 }); }

package/lib/vendor/blamejs/test/layer-0-primitives/dnssec.test.js

@@ -390,12 +390,106 @@ function testKeyTagCollision() {
   check("verifyChain: validates despite a colliding-tag key in the signed set", out.ok === true);
 }
 
+// Sign a DS RRset (type 43) with a parent EC key — mirrors
+// _signDnskeyRrset but for the DS record type.
+function _signDsRrset(zone, dsRdatas, parentPriv, parentSignerRdata, inc, exp) {
+  var owner = _canonName(zone), ttl = _u32b(3600);
+  var labels = zone.replace(/\.$/, "") === "" ? 0 : zone.replace(/\.$/, "").split(".").length;
+  var keyTag = b.network.dns.dnssec.keyTag(parentSignerRdata);
+  var sorted = dsRdatas.slice().sort(Buffer.compare);
+  var rrs = [];
+  sorted.forEach(function (rd) { rrs.push(owner, _u16b(43), _u16b(1), ttl, _u16b(rd.length), rd); });
+  var prefix = Buffer.concat([_u16b(43), Buffer.from([13, labels]), ttl, _u32b(exp), _u32b(inc), _u16b(keyTag), _canonName(zone)]);
+  var signed = Buffer.concat([prefix].concat(rrs));
+  var signature = nodeCrypto.sign("sha256", signed, { key: parentPriv, dsaEncoding: "ieee-p1363" });
+  return { algorithm: 13, labels: labels, originalTtl: 3600, expiration: exp, inception: inc, keyTag: keyTag, signerName: zone, signature: signature };
+}
+function _dsRdata(tag, alg, digest) {
+  return Buffer.concat([_u16b(tag), Buffer.from([alg, 2]), digest]);   // keyTag || alg || digestType=2(SHA-256) || digest
+}
+
+// The per-response signature-validation budget scales with chain depth, so
+// a legitimate deep delegation (here 11 links → ~21 verifies, well past the
+// old fixed 16) validates rather than hitting dnssec/validation-budget-
+// exceeded (the regression Codex flagged on PR #236).
+function testDeepChainBudget() {
+  var now = Math.floor(Date.now() / 1000), inc = now - 60, exp = now + 86400;
+  var N = 11;
+  var keys = [];
+  for (var i = 0; i < N; i++) {
+    var kp = nodeCrypto.generateKeyPairSync("ec", { namedCurve: "prime256v1" });
+    keys.push({ rd: _ecDnskey(kp.publicKey), priv: kp.privateKey, zone: "z" + i + "." });
+  }
+  var links = [];
+  for (var j = 0; j < N; j++) {
+    var k = keys[j];
+    var link = {
+      zone:        k.zone,
+      dnskeys:     [k.rd],
+      dnskeyRrsig: _signDnskeyRrset(k.zone, [k.rd], k.priv, k.rd, inc, exp),
+    };
+    if (j > 0) {
+      // DS of THIS zone's key, signed by the PARENT (previous link's key).
+      var digest = nodeCrypto.createHash("sha256").update(Buffer.concat([_canonName(k.zone), k.rd])).digest();
+      var dsRd = _dsRdata(b.network.dns.dnssec.keyTag(k.rd), 13, digest);
+      link.dsRdatas = [dsRd];
+      link.dsRrsig  = _signDsRrset(k.zone, [dsRd], keys[j - 1].priv, keys[j - 1].rd, inc, exp);
+    }
+    links.push(link);
+  }
+  // Trust anchor = DS digest of the root (link 0) key.
+  var rootDigest = nodeCrypto.createHash("sha256").update(Buffer.concat([_canonName(keys[0].zone), keys[0].rd])).digest();
+  var anchor = [{ keyTag: b.network.dns.dnssec.keyTag(keys[0].rd), algorithm: 13, digestType: 2, digest: rootDigest }];
+  var out = b.network.dns.dnssec.verifyChain({ links: links, trustAnchors: anchor, at: new Date(now * 1000) });
+  check("deep chain (11 links, ~21 verifies) validates under the depth-scaled budget",
+    out.ok === true && out.path.length === N);
+}
+
+// KeyTrap (CVE-2023-50387) amplification caps. The caps fire on COUNT
+// checks before any signature verification, so a single real EC DNSKEY
+// rdata repeated to hit each threshold is enough.
+function testKeyTrapCaps() {
+  function code(fn) { try { fn(); return "NO-THROW"; } catch (e) { return e.code; } }
+  var kp = nodeCrypto.generateKeyPairSync("ec", { namedCurve: "prime256v1" });
+  var rd = _ecDnskey(kp.publicKey);
+  var tag = b.network.dns.dnssec.keyTag(rd);
+  var now = Math.floor(Date.now() / 1000);
+  var rrsig = { algorithm: 13, labels: 1, originalTtl: 3600, expiration: now + 86400,
+    inception: now - 60, keyTag: tag, signerName: "test.", signature: Buffer.alloc(64) };
+  var anchor = [{ keyTag: tag, algorithm: 13, digestType: 2, digest: Buffer.alloc(32) }];
+
+  // > MAX_COLLIDING_KEYS (4) keys sharing one tag (5 identical rdatas all
+  // resolve to the same tag) → refused before any verify.
+  var fiveSameTag = [rd, rd, rd, rd, rd];
+  check("KeyTrap: >4 same-tag DNSKEY candidates refused",
+    code(function () { b.network.dns.dnssec.verifyChain({
+      links: [{ zone: "test.", dnskeys: fiveSameTag, dnskeyRrsig: rrsig }],
+      trustAnchors: anchor, at: new Date(now * 1000) }); }) === "dnssec/too-many-colliding-keys");
+
+  // > MAX_DNSKEYS_PER_ZONE (64) in one zone's RRset → refused.
+  var bigSet = []; for (var i = 0; i < 65; i++) bigSet.push(rd);
+  check("KeyTrap: oversize DNSKEY RRset (>64) refused",
+    code(function () { b.network.dns.dnssec.verifyChain({
+      links: [{ zone: "test.", dnskeys: bigSet, dnskeyRrsig: rrsig }],
+      trustAnchors: anchor, at: new Date(now * 1000) }); }) === "dnssec/too-many-dnskeys");
+
+  // A name encoding to > 255 octets (128 single-char labels = 257 octets)
+  // is refused at canonicalization (RFC 1035 §2.3.4) — bounds the NSEC3
+  // closest-encloser label enumeration.
+  var longName = new Array(129).join("a.") + "a";   // 129 labels of "a"
+  check("KeyTrap: name exceeding 255 octets refused",
+    code(function () { b.network.dns.dnssec.verifyDs({ ownerName: longName,
+      dnskeyRdata: rd, ds: { keyTag: tag, algorithm: 13, digestType: 2, digest: Buffer.alloc(32) } }); }) === "dnssec/bad-name");
+}
+
 async function run() {
   testSurface();
   testRealVectors();
   testRefusals();
   testVerifyDs();
   testVerifyChain();
+  testKeyTrapCaps();
+  testDeepChainBudget();
   testNsec3Real();
   testNsec3Caps();
   testNsec3OptOut();

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/blamejs-shop",
-  "version": "0.2.2",
+  "version": "0.2.3",
   "description": "Open-source framework built on blamejs. Vendored stack, zero npm runtime deps, PQC-first crypto, security-on by default.",
   "main": "lib/index.js",
   "scripts": {