@blamejs/blamejs-shop 0.4.89 → 0.4.91

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.91 (2026-06-24) — **A gift-card refund is now linked to the order it reverses, so an order's gift-card settlement history is complete.** When a refund returns money to a gift card (a cancelled or refunded order that had been paid with the card), the ledger credit now records the order it reverses in the structured order field, not only as a free-text reference. Previously a query for a given order's gift-card movements returned the debits that spent the card but not the refund credits that returned money to it, so the order's gift-card settlement history read as one-sided. The refund credit now carries the order link, so the order's gift-card history shows both the spend and the matching refund. No configuration changes, and existing gift-card behavior — balances, overdraft refusal, and the per-card tamper-evident hash chain — is unchanged. **Fixed:** *Refund-to-gift-card credits carry the order they reverse* — giftCardLedger.credit now accepts an optional order_id, and the order-cancellation/refund path that returns a redeemed amount to a gift card passes the order it reverses. The ledger's transactionsForOrder(order_id) lookup keys on that structured field, so it now returns the refund credits flowing back to a card alongside the debits that drained it for the order — previously the credits were keyed only by a free-text reference and were absent from the lookup. Each refund credit still participates in the per-card hash chain (the order link is covered by the row hash), and credits with no associated order (promotional or manual top-ups) are unaffected.
+
+- v0.4.90 (2026-06-24) — **Credit-account releases and aging now attribute payments to orders correctly, so cancelling a paid order can't erase another order's debt.** Two related accounting fixes for B2B credit accounts, no configuration or schema changes. On a credit account, payments are revolving — they pay down the oldest outstanding charge first across all of a customer's orders. Releasing the hold on a cancelled or returned order previously reduced the balance by that order's full charge without accounting for payments already applied to it, so on an account with more than one order, cancelling an order that a payment had effectively settled drove the balance below what was genuinely owed and silently erased another order's debt from the outstanding total and the aging report. A release now reduces the balance only by the order's still-unpaid amount (its charges minus the payments attributed to it, oldest-first), so a cancelled-but-paid order is a no-op and every other order's genuine debt is preserved. Separately, the aging report was pooling order-scoped releases together with order-agnostic payments into a single oldest-first settlement, so releasing a recent order could settle the oldest charge and report a genuinely past-due balance as current; the report now nets each order's releases against that order's own charges before applying payments oldest-first, so the past-due buckets reflect reality. The outstanding total is unchanged in every case — only the misattribution is corrected. Upgrade to pick it up. **Changed:** *Vendored blamejs framework refreshed to 0.15.20* — The vendored framework moves from 0.15.19 to 0.15.20, with no API or configuration change. It refreshes the bundled Mozilla public-suffix list (used for cookie-scope, same-site, and DMARC/BIMI domain classification), updates the bundled WebAuthn server library to 13.3.2 (improved passkey attestation certificate-path validation), and corrects the vendored-dependency SBOM version metadata so CVE scanners match advisories against the versions actually shipped. **Fixed:** *Releasing a credit-account order caps at its unpaid amount, not its full charge* — creditLimits.releaseHold now reduces the outstanding balance only by the target order's unpaid exposure — its charges and holds, minus its own prior releases, minus the revolving payments attributed to it under an oldest-order-first allocation — capped at the live balance. Previously it reduced the balance by the order's full net charge and ignored payments entirely (payments carry no order reference), so on a multi-order account, cancelling an order that a payment had already settled released credit that was never owed and erased another order's genuine debt from the outstanding total. A cancelled order whose charge has effectively been paid now releases nothing (the request is refused as having no outstanding amount); a genuinely unpaid order still releases its full exposure. The check is a single atomic statement, so it stays correct under concurrent releases and payments. · *Aging report nets order releases against their own order before applying payments* — creditLimits.agingReport no longer pools order-scoped releases with order-agnostic payments into one oldest-first drain. It first nets each order's releases against that order's own charges (a release reverses its own order's charge, never another's), then applies the revolving payment pool oldest-charge-first across what remains. Previously, releasing a recent order could settle the oldest charge in the pooled drain, masking a genuinely past-due balance as current and inverting the aging buckets that drive dunning and collections. The total outstanding is identical to before — only the bucket distribution is corrected — and it uses the same payment-attribution model as the release cap, so a release and the report can never disagree on an order's unpaid amount.
+
 - v0.4.89 (2026-06-24) — **Store-credit wallet balances are now tamper-evident, and concurrent gift-card ledger writes retry reliably in production.** The store-credit ledger gains the same per-customer cryptographic hash chain the gift-card ledger already carries, so a balance can no longer be silently altered by a direct database edit. Each wallet row now links to the prior one with a SHA3-512 hash over its contents, and a new verifyChain check recomputes the chain and reports the first row that doesn't link — a denormalized balance snapshot was previously a value, not a proof, so a row edit that inflated a balance or a deletion that dropped a debit passed a balance read undetected. The same change makes the balance computation safe under concurrency through a chain-parent fence and a re-read-and-retry on contention. Separately, a latent reliability bug in the gift-card ledger's concurrent-write retry is fixed: it detected a write collision by matching the database's error text, but the production data-layer redacts that text to a generic error, so a genuine collision between two writes against the same gift card could surface as a failed request instead of retrying — both ledgers now detect a collision by re-reading the chain tip, which is robust regardless of how the error is reported. No configuration changes; the store-credit schema additions apply automatically on upgrade. **Added:** *Store-credit ledger is tamper-evident with a per-customer hash chain* — Every store-credit wallet row now carries prev_hash + row_hash columns forming a per-customer SHA3-512 chain: row_hash = SHA3-512(prev_hash || canonical-json(row fields)), anchored at a genesis sentinel for a wallet's first row. A direct database edit that inflates a balance snapshot, or a deletion that drops a debit, breaks the chain at that row. A new storeCredit.verifyChain(customer_id) walks the wallet and returns the first divergence (or confirms the chain is intact); a wallet whose hash columns have all been cleared reads as unanchored rather than trusting the unverifiable rows. Because deleting a chain's most-recent rows leaves the remaining prefix internally consistent — a truncation an append-only chain can't detect on its own — verifyChain optionally accepts a trusted anchor (a row count and head hash captured from an earlier snapshot) and reports a possible truncation when the chain has fallen below it. The balance and occurred-at values are now computed in the application and protected under concurrency by a chain-parent uniqueness fence — a write derived from a stale view of the wallet collides and is retried against the current tip, so the denormalized balance stays exact under concurrent credits, debits, expirations, and the scheduled expiry sweep. **Fixed:** *Concurrent gift-card and store-credit ledger writes retry reliably in production* — The ledger retries a write that loses a race against a concurrent write to the same entity. It previously recognized that collision by matching the database engine's constraint-violation text — but the production data-layer redacts that text to a generic error, so in production a genuine collision was not recognized and the write surfaced as a failed request instead of retrying (the path only worked under the in-memory test engine, where the full error text survives). Both the gift-card ledger and the new store-credit chain now detect a collision by re-reading the chain tip after a failed write: if the tip has advanced past the row the write tried to extend, a competing write claimed the slot and the write is retried; otherwise the original error is surfaced. The retry is now robust regardless of how the underlying error is reported.
 
 - v0.4.88 (2026-06-24) — **Refreshes the vendored framework to 0.15.19 and makes the vendored-dependency SBOM a committed, drift-guarded artifact.** Two supply-chain changes, no application configuration changes. The vendored blamejs framework moves from 0.15.16 to 0.15.19, picking up a set of upstream correctness and confidentiality fixes that ride inside the primitives the store already composes: a rejection on an established encrypted-API session is now returned inside the encrypted session envelope instead of disclosing which check failed in cleartext; stapled-OCSP response-freshness validation is restored; the DPoP proof's request-URI reconstruction now peer-gates forwarded scheme/host headers; the bundled public-suffix list is refreshed; and a family of credential/certificate verifiers continues to fail closed on an unparseable timestamp. Separately, the vendored-dependency SBOM (sbom.vendored.cdx.json) is now committed to the repository and mechanically projected from the vendored manifest, so its component versions can never silently fall behind what actually ships under lib/vendor/: a build gate fails on any drift, and the published, signed SBOM is the same verified file rather than one regenerated at publish time. Upgrade to pick both up. **Added:** *Vendored-dependency SBOM is a committed, drift-guarded artifact* — sbom.vendored.cdx.json — the CycloneDX 1.6 SBOM describing what ships under lib/vendor/ — is now committed to the repository and generated as a deterministic projection of lib/vendor/MANIFEST.json (the source of truth for the vendored version, license, and source). The vendor refresh regenerates it automatically, and a build gate fails if the committed SBOM drifts from the vendored manifest, so its component versions can never silently fall behind the vendored tree — the same protection the changelog, the release-notes rollup, and the asset-manifest already carry. The signed SBOM published as a release asset is now this same verified file rather than one regenerated at publish time, so the artifact downstream scanners consume is byte-reproducible from the committed source. **Changed:** *Vendored blamejs framework refreshed to 0.15.19* — The vendored framework moves from 0.15.16 to 0.15.19. The changes are upstream correctness and confidentiality fixes that ride inside the primitives the store already uses, with no API or configuration change: a rejection on an established encrypted-API session is now encrypted inside the session envelope rather than returned as a cleartext reason that disclosed which check failed; stapled-OCSP response-freshness enforcement (RFC 6960) is restored after a parsing regression had it reject every response; the DPoP htu reconstruction and the new request-host resolver only honor forwarded scheme/host headers from a declared trusted proxy; the bundled Mozilla public-suffix list (used for cookie-scope and same-site decisions) is refreshed to current upstream; and the credential/certificate validity-window verifiers continue to refuse a present-but-unparseable timestamp instead of skipping the check.

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.89",
+  "version": "0.4.91",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-imfe0otYErcB8rr2h6KLSGTtStirysptpXETSPY4zLv3bZoIT75Lo1dOvkOav+xL",

package/lib/credit-limits.js

@@ -256,6 +256,44 @@ function create(opts) {
   var _BAL_SUB = "COALESCE((SELECT balance_after_minor FROM credit_transactions " +
                  "WHERE customer_id = ?2 ORDER BY occurred_at DESC LIMIT 1), 0)";
 
+  // The UNPAID exposure of ONE order (?4) — what releaseHold may release
+  // without consuming balance that belongs to OTHER orders' genuine unpaid
+  // charges. Computed PER CHARGE/HOLD ROW (not collapsed per order), row-
+  // for-row identical to the agingReport recompute, so the two surfaces can
+  // never disagree even when an order carries more than one charge/hold row
+  // (a hold plus a capture, or an injected duplicate). The attribution
+  // model: a RELEASE nets only against its OWN order's rows, oldest-first;
+  // a PAYMENT is revolving (order_id=NULL) and drains the post-release row
+  // remainders global oldest-first. So each row's unpaid = its amount,
+  // minus the release applied to it (its own order's release filling that
+  // order's rows oldest-first), minus the FIFO slice of the payment pool
+  // that overlaps the row's position [cum_rem_before, cum_rem_before+rem) on
+  // the global oldest-first number line. An order's unpaid is the SUM of its
+  // rows' unpaid. Expressed as one correlated subquery (nested CTEs + window
+  // functions) so it composes inside the SAME single-statement atomic write
+  // as _BAL_SUB: a concurrent payment/release commits first and this
+  // subquery re-evaluates against it, so race-safety is preserved with no
+  // app-side read-then-write. References ?2 (customer_id) + ?4 (order_id),
+  // both bound by _appendTxnAtomic.
+  var _UNPAID_SUB =
+    "COALESCE((WITH " +
+    "pay AS (SELECT COALESCE(SUM(amount_minor), 0) AS p " +
+    "  FROM credit_transactions WHERE customer_id = ?2 AND kind = 'payment'), " +
+    "rel AS (SELECT order_id, COALESCE(SUM(amount_minor), 0) AS r " +
+    "  FROM credit_transactions WHERE customer_id = ?2 AND kind = 'release' GROUP BY order_id), " +
+    "rows0 AS (SELECT id, order_id, occurred_at, amount_minor, " +
+    "  COALESCE(SUM(amount_minor) OVER (PARTITION BY order_id ORDER BY occurred_at, id " +
+    "    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING), 0) AS cum_own_before " +
+    "  FROM credit_transactions WHERE customer_id = ?2 AND kind IN ('charge', 'hold')), " +
+    "rel_applied AS (SELECT r0.id, r0.order_id, r0.occurred_at, " +
+    "  r0.amount_minor - MAX(0, MIN(r0.amount_minor, COALESCE(rel.r, 0) - r0.cum_own_before)) AS rem " +
+    "  FROM rows0 r0 LEFT JOIN rel ON rel.order_id = r0.order_id), " +
+    "rows1 AS (SELECT order_id, rem, " +
+    "  COALESCE(SUM(rem) OVER (ORDER BY occurred_at, id ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING), 0) AS cum_rem_before " +
+    "  FROM rel_applied) " +
+    "SELECT COALESCE(SUM(rem - MAX(0, MIN(cum_rem_before + rem, (SELECT p FROM pay)) - MAX(cum_rem_before, 0))), 0) " +
+    "FROM rows1 WHERE order_id = ?4), 0)";
+
   // Append a ledger transaction ATOMICALLY. The new balance, the
   // strictly-monotonic occurred_at, and the operation's invariant
   // (credit limit / sufficient balance / outstanding charge) are all
@@ -616,27 +654,28 @@ function create(opts) {
         throw closed;
       }
 
-      // Net exposure to this order — charge + hold sums minus prior
-      // release sums — capped at the live balance, computed and written
-      // in ONE atomic statement. The racy read-sum-then-write this
-      // replaced let two concurrent releases (or a release racing a
-      // payment) both read the same remaining/balance and both write,
-      // double-releasing the order and corrupting the running balance.
-      // The guard refuses when nothing is outstanding (never charged /
-      // already fully released) or the balance is drained, so a release
-      // can't drive the ledger negative. Capping at _BAL_SUB stays
-      // defensive against operator-induced ledger drift.
-      var remainingSub = "COALESCE((SELECT SUM(CASE " +
-        "WHEN kind IN ('charge', 'hold') THEN amount_minor " +
-        "WHEN kind = 'release' THEN -amount_minor ELSE 0 END) " +
-        "FROM credit_transactions WHERE customer_id = ?2 AND order_id = ?4), 0)";
-      var toReleaseExpr = "CASE WHEN " + remainingSub + " < " + _BAL_SUB +
-        " THEN " + remainingSub + " ELSE " + _BAL_SUB + " END";
+      // UNPAID exposure of this order — its net charge minus the FIFO
+      // payments attributed to it (_UNPAID_SUB) — capped at the live
+      // balance, computed and written in ONE atomic statement. Subtracting
+      // the payment attribution is the fix for the multi-order over-release:
+      // the cap used to be the order's GROSS net charge and never subtracted
+      // payments (payments are order-agnostic, order_id=NULL), so releasing a
+      // conceptually-paid order in a multi-order account consumed balance
+      // that belonged to OTHER orders' genuine unpaid charges and erased
+      // their debt. Keeping it a single correlated-subquery statement
+      // preserves the original race-safety (a concurrent release/payment
+      // commits first and _UNPAID_SUB / _BAL_SUB re-evaluate against it). The
+      // guard refuses when the order is fully paid / released / never
+      // charged, or the balance is drained, so a release can't drive the
+      // ledger negative. Capping at _BAL_SUB stays defensive against
+      // operator-induced ledger drift.
+      var toReleaseExpr = "CASE WHEN " + _UNPAID_SUB + " < " + _BAL_SUB +
+        " THEN " + _UNPAID_SUB + " ELSE " + _BAL_SUB + " END";
       var written = await _appendTxnAtomic(
         customerId, "release", orderId, null, requested,
         toReleaseExpr,                                   // amount actually released
         _BAL_SUB + " - (" + toReleaseExpr + ")",         // new balance
-        remainingSub + " > 0 AND " + _BAL_SUB + " > 0",  // nothing outstanding / drained -> refuse
+        _UNPAID_SUB + " > 0 AND " + _BAL_SUB + " > 0",   // fully paid/released/drained -> refuse
         [],
       );
       if (!written) {
@@ -759,23 +798,80 @@ function create(opts) {
       }
       var terms = acct.payment_terms_days;
 
-      // Walk all charge/hold rows oldest-first. Apply payments +
-      // releases FIFO against the oldest outstanding amounts. What
-      // remains in each charge row after settlement is the
-      // outstanding slice for that age bucket.
+      // Walk all charge/hold rows oldest-first, then settle in two passes
+      // that honor what each settlement kind actually reverses:
+      //
+      //   1. A RELEASE is intrinsically order-scoped — it reverses ITS
+      //      order's charge — so it nets only against that order's OWN
+      //      charge slices (oldest-first). Pooling releases with payments
+      //      into one global FIFO drain (the prior behavior) let a release
+      //      of a RECENT order settle the OLDEST charge, masking a genuinely
+      //      past-due balance as current and inverting the aging buckets.
+      //   2. A PAYMENT is revolving (order_id=NULL) — it pays down the
+      //      OLDEST outstanding charge first across ALL orders. It drains
+      //      AFTER the per-order release netting, over whatever net slices
+      //      remain.
+      //
+      // This is the SAME attribution model releaseHold's _UNPAID_SUB cap
+      // uses (own-order releases, then global-FIFO payments), so the report
+      // and a release can never disagree on an order's unpaid exposure. The
+      // total is unchanged (charges − releases − payments); only the bucket
+      // distribution is corrected. The (occurred_at, id) ordering matches the
+      // ledger's monotonic stamping and _UNPAID_SUB's FIFO key.
       var chargeRows = (await query(
-        "SELECT amount_minor, occurred_at, order_id FROM credit_transactions " +
+        "SELECT id, amount_minor, occurred_at, order_id FROM credit_transactions " +
         "WHERE customer_id = ?1 AND kind IN ('charge', 'hold') " +
-        "ORDER BY occurred_at ASC",
+        "ORDER BY occurred_at ASC, id ASC",
         [customerId],
       )).rows;
 
-      var settleRow = (await query(
+      // Per-order release totals — netted against that order's own charges.
+      var relRows = (await query(
+        "SELECT order_id, COALESCE(SUM(amount_minor), 0) AS rel FROM credit_transactions " +
+        "WHERE customer_id = ?1 AND kind = 'release' GROUP BY order_id",
+        [customerId],
+      )).rows;
+      var relByOrder = Object.create(null);
+      for (var ri = 0; ri < relRows.length; ri += 1) {
+        relByOrder[relRows[ri].order_id] = relRows[ri].rel;
+      }
+
+      // Order-agnostic payment pool — drains FIFO AFTER release netting.
+      var paySettleRow = (await query(
         "SELECT COALESCE(SUM(amount_minor), 0) AS total FROM credit_transactions " +
-        "WHERE customer_id = ?1 AND kind IN ('payment', 'release')",
+        "WHERE customer_id = ?1 AND kind = 'payment'",
         [customerId],
       )).rows[0];
-      var toSettle = settleRow ? settleRow.total : 0;
+      var toSettle = paySettleRow ? paySettleRow.total : 0;
+
+      var slices = [];
+      for (var si = 0; si < chargeRows.length; si += 1) {
+        slices.push({
+          order_id:    chargeRows[si].order_id,
+          occurred_at: chargeRows[si].occurred_at,
+          remaining:   chargeRows[si].amount_minor,
+        });
+      }
+      // Pass 1: net each order's releases against its OWN charge slices,
+      // oldest-first (slices are already in global oldest-first order).
+      for (var p1 = 0; p1 < slices.length; p1 += 1) {
+        var sRel = slices[p1];
+        var rel  = relByOrder[sRel.order_id] || 0;
+        if (rel > 0) {
+          var rd = rel > sRel.remaining ? sRel.remaining : rel;
+          sRel.remaining -= rd;
+          relByOrder[sRel.order_id] = rel - rd;
+        }
+      }
+      // Pass 2: drain the order-agnostic payment pool FIFO across the
+      // remaining net slices, oldest-first.
+      for (var p2 = 0; p2 < slices.length && toSettle > 0; p2 += 1) {
+        var sPay = slices[p2];
+        if (sPay.remaining <= 0) continue;
+        var pd = toSettle > sPay.remaining ? sPay.remaining : toSettle;
+        sPay.remaining -= pd;
+        toSettle       -= pd;
+      }
 
       var buckets = {};
       buckets[AGE_BUCKETS.CURRENT] = 0;
@@ -784,22 +880,15 @@ function create(opts) {
       buckets[AGE_BUCKETS.D90]     = 0;
 
       var total = 0;
-      for (var i = 0; i < chargeRows.length; i += 1) {
-        var row = chargeRows[i];
-        var remaining = row.amount_minor;
-        if (toSettle > 0) {
-          var settled = toSettle > remaining ? remaining : toSettle;
-          remaining -= settled;
-          toSettle  -= settled;
-        }
+      for (var i = 0; i < slices.length; i += 1) {
+        var remaining = slices[i].remaining;
         if (remaining <= 0) continue;
-        var ageMs   = now - row.occurred_at;
+        var ageMs   = now - slices[i].occurred_at;
         var ageDays = Math.floor(ageMs / MS_PER_DAY);
-        // Bucket by days-past-due so the report reads the same
-        // regardless of the account's payment terms — a net-15 and
-        // a net-60 account both report `current` against not-yet-
-        // due charges, then advance through 30 / 60 / 90+ buckets
-        // measured from the due date.
+        // Bucket by days-past-due so the report reads the same regardless of
+        // the account's payment terms — a net-15 and a net-60 account both
+        // report `current` against not-yet-due charges, then advance through
+        // 30 / 60 / 90+ buckets measured from the due date.
         var pastDue = ageDays - terms;
         var bucket;
         if (pastDue <= 0)        bucket = AGE_BUCKETS.CURRENT;

package/lib/gift-card-ledger.js

@@ -51,7 +51,7 @@
  *   degrade gracefully rather than refusing.
  *
  *   Surface:
- *     - credit({ gift_card_id, amount_minor, source, source_ref, occurred_at? })
+ *     - credit({ gift_card_id, amount_minor, source, source_ref, order_id?, occurred_at? })
  *     - debit({ gift_card_id, amount_minor, order_id, occurred_at? })
  *     - expire({ gift_card_id, amount_minor, reason, occurred_at? })
  *     - balance(gift_card_id)
@@ -341,6 +341,11 @@ function create(opts) {
       var amount     = _amountMinor(input.amount_minor, "amount_minor");
       var source     = _source(input.source);
       var sourceRef  = _sourceRef(input.source_ref, "source_ref");
+      // Optional structured order link — a refund_to_giftcard credit names
+      // the order it reverses, so transactionsForOrder(orderId) returns the
+      // money flowing BACK to the card alongside the debits that drained it.
+      // Other credit sources (promotional / manual top-ups) carry no order.
+      var orderId = input.order_id == null ? null : _uuid(input.order_id, "order_id");
       var requested = _epochMs(input.occurred_at, "occurred_at");
       if (requested == null) requested = _now();
 
@@ -349,7 +354,7 @@ function create(opts) {
           amount:    amount,
           source:    source,
           sourceRef: sourceRef,
-          orderId:   null,
+          orderId:   orderId,
           after:     latest.balance + amount,
           ts:        _resolveOccurredAt(requested, latest.occurred_at),
           guarded:   false,
@@ -363,6 +368,7 @@ function create(opts) {
         amount_minor:        amount,
         source:              source,
         source_ref:          sourceRef,
+        order_id:            orderId,
         balance_after_minor: w.balance_after_minor,
         occurred_at:         w.occurred_at,
       };

package/lib/order.js

@@ -394,6 +394,7 @@ function create(opts) {
               amount_minor: rev.amount_minor,
               source:       "refund_to_giftcard",
               source_ref:   orderId,
+              order_id:     orderId,
             });
           } catch (_ledgerErr) { /* drop-silent — the card-row balance restore above is authoritative; the ledger credit is the audit trail */ }
         }

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.15.19",
-      "tag": "v0.15.19",
+      "version": "0.15.20",
+      "tag": "v0.15.20",
       "license": "Apache-2.0",
       "author": "blamejs contributors",
       "source": "https://github.com/blamejs/blamejs",
@@ -841,6 +841,7 @@
         "release-notes/v0.15.18.json": "lib/vendor/blamejs/release-notes/v0.15.18.json",
         "release-notes/v0.15.19.json": "lib/vendor/blamejs/release-notes/v0.15.19.json",
         "release-notes/v0.15.2.json": "lib/vendor/blamejs/release-notes/v0.15.2.json",
+        "release-notes/v0.15.20.json": "lib/vendor/blamejs/release-notes/v0.15.20.json",
         "release-notes/v0.15.3.json": "lib/vendor/blamejs/release-notes/v0.15.3.json",
         "release-notes/v0.15.4.json": "lib/vendor/blamejs/release-notes/v0.15.4.json",
         "release-notes/v0.15.5.json": "lib/vendor/blamejs/release-notes/v0.15.5.json",
@@ -1547,7 +1548,7 @@
         ".npmrc": "sha256:66f104e7d07c496d2d0409988225e8c0e4ceb8d247dbcac3be75b2128d20ce66",
         ".pinact.yaml": "sha256:0213ffda55961dc49b64c0a5dfa3c0567419633b1499d57eaf7c8d842d7da6c7",
         "ARCHITECTURE.md": "sha256:9b1c8d2b1b7a41838eb348b0a008e4b4369718fd72bfe2974b37155f7536d35b",
-        "CHANGELOG.md": "sha256:ebd9e3a79a0dce5518430a52c9c6e24cbf7bad0406bbed2c4e7ad5eb1ab297c6",
+        "CHANGELOG.md": "sha256:4642c9fe7ab6aacfbf5b95e3780834b6b1fb4f485139571171d8a30eb702cde7",
         "CODE_OF_CONDUCT.md": "sha256:148a281960fff7c2fe6554dab66da572c72245ddeb00b0d14811558397bff386",
         "CONTRIBUTING.md": "sha256:bb4dbdbc8598da31dbce653a8ed322e08ff46560173f2eb67a4d684653948332",
         "GOVERNANCE.md": "sha256:906df6afb1f552b27b9acb50f7f96c47b917a2f1021cd4e987dbf4ee0e0a821b",
@@ -1557,7 +1558,7 @@
         "NOTICE": "sha256:f487fa47a11aca0f89e2615cdd3c713e9842abf7a30d8d328eeeae1c864aa774",
         "README.md": "sha256:3ddcc197b003da0b02db8bdd1aef1e943c94f7eab613c633d6a45bb11d0a80e9",
         "SECURITY.md": "sha256:23f7ee4a44f21e433ed1d3c6f414575eb3e30f66a328422973a1109a276c537b",
-        "api-snapshot.json": "sha256:719da0f2483fb5672ee09e398f4d85304c875f6f9df96f21ad32cdc3aa1cc3b5",
+        "api-snapshot.json": "sha256:7ca3b73f197b253072a2210417668acf336bb36a8407556e7e3663b0b1543aa9",
         "assets/BlameJS_Logo.png": "sha256:3c65699753c771b48ef9ac7f45bb40815ec19a23afcdd0cd30ef4601bbbe293e",
         "assets/BlameJS_Logo.svg": "sha256:dda44f3fb1343d5de9db6b1fcdb75fc649c57e7a99a8e8239fcf852e3841e1a8",
         "bench/README.md": "sha256:74202f2507fd840bfc1ac6c681975d9273cf36cca6e0f72655f138337304033c",
@@ -2298,7 +2299,7 @@
         "lib/vc.js": "sha256:554cf29ea712b231256e1eaa75f6b1f1d39c392aac86b33e818d52e956ea83ae",
         "lib/vendor-data.js": "sha256:ddb77b33d89a2c5345deca98eacb45695d4c8a70014bc5df22c7393f52e11416",
         "lib/vendor/.vendor-data-pubkey": "sha256:73a935b8c72f55d821c22ddb8188453bab324f80d229d033a0a1549819a1f096",
-        "lib/vendor/MANIFEST.json": "sha256:09194d50f99999485fb525da118afd815c475be0ef4f6e58fbc3f41ffd91d1dd",
+        "lib/vendor/MANIFEST.json": "sha256:c2b9e40fb993db0f92c49154a5ac078e01324ccd02a19985e38186da06dd7338",
         "lib/vendor/bimi-trust-anchors.data.js": "sha256:aa7a4d33b65a68422a2a2c1670177689f66fdcaa08bd2514d78798b827bd1608",
         "lib/vendor/bimi-trust-anchors.pem": "sha256:81ff9f5ab3c9774132c845684e783be95cf73146f8b670d964105f0a3765b4b4",
         "lib/vendor/common-passwords-top-10000.data.js": "sha256:87b223beca89f33d2c2c32a2cfda0bc187e58061de40e7127bb5ffc4258c6e2a",
@@ -2307,9 +2308,9 @@
         "lib/vendor/noble-curves.cjs": "sha256:ebf254d5eb56aef8705a1c4af9603f47987b4870a9bb5e657e06907b701e2731",
         "lib/vendor/noble-post-quantum.cjs": "sha256:f9190309daadca4c2e2cc2b76beaa6b96e463429cc3c390bd9f0ceaf7b588c68",
         "lib/vendor/pki.cjs": "sha256:9bbc191afaaa2b1e5757f00480457c08134cdc2c55d541df18d9155bba9cbf77",
-        "lib/vendor/public-suffix-list.dat": "sha256:0adddeb62057d8d40799dffb29fe14f65dd009259afe02eb2f0b4602b791aae6",
-        "lib/vendor/public-suffix-list.data.js": "sha256:82af512cacf0fd2c60925e63f877b69477b1b2f7bb5af698fd862af61369902e",
-        "lib/vendor/simplewebauthn-server.cjs": "sha256:f359a782ac57e3ff56ac71083d17f5c082f88ab49d645fc2bede398b47adebdb",
+        "lib/vendor/public-suffix-list.dat": "sha256:42c4f3544726fa2feb4f304c889c5e391feb5d28080c9b6356ff82e267a93706",
+        "lib/vendor/public-suffix-list.data.js": "sha256:c840d9ae5c6bf4a07967340a5c649df2c6a66a287db41e408461c46cc32348e6",
+        "lib/vendor/simplewebauthn-server.cjs": "sha256:49411d893f5e9b0e2fcaa564b4ec7921f73a9a06229b5e53d49c1453ea1a365c",
         "lib/vendor/vendor-data-pubkey.js": "sha256:a12afa34cd7472e2eaebad2fcd44714102d3edd0601e45769404124a513926d0",
         "lib/vex.js": "sha256:b45c1c9729dfc69f2140478d46eec91f47da94b5f440be36fa825cb733a718fc",
         "lib/watcher.js": "sha256:8618da919affabbe4c4d33915647b3ee4b27e6ea091638f032d4bfead797baf8",
@@ -2328,7 +2329,7 @@
         "oss-fuzz/projects/blamejs/README.md": "sha256:ae13b7bb79ed8d69b1b3276e5562807a0349fb6e6b7d11cf1f683aad1eafdb4b",
         "oss-fuzz/projects/blamejs/build.sh": "sha256:0ced1cf21782c97be7f8d74faf5e27a308b60b2f858836fb5ca3b8c4e939a8f7",
         "oss-fuzz/projects/blamejs/project.yaml": "sha256:59f2cb83aa622325a175b77416fe155be15b70a9c798bd1a78bba05763b1b03d",
-        "package.json": "sha256:c625373887cfae872dde0fca9ea6955278d6fc721128c04bbd01a31986b9d409",
+        "package.json": "sha256:7409a04e0673a297045ce2248e196cb4f856f2a037af73e837b0264b76984071",
         "release-notes/v0.0.x.json": "sha256:7a49819f30068ee119000cad7010194882bb8bfaa12acbdab4dfc066efb7982f",
         "release-notes/v0.1.x.json": "sha256:6742a8c17f947c5cb76f69dead7eea86b942d80621d914b774ba5488e09937e5",
         "release-notes/v0.10.x.json": "sha256:fe498045daf88337bd3d987e5964aa42c99a50e1685b6f09e51f698b8687726f",
@@ -2349,6 +2350,7 @@
         "release-notes/v0.15.18.json": "sha256:c8b3ce7af0f7863cdc3f5179f0525469331720a80b741b73236fdd6f4243bbaa",
         "release-notes/v0.15.19.json": "sha256:8c6a745accd2c551953464991bb23547e8cf87286d57938c57080755785e58b5",
         "release-notes/v0.15.2.json": "sha256:36e1423dda94ed4e55c660e0fae882019005d8de3ee5e3b6ac4f38ccf8e744a2",
+        "release-notes/v0.15.20.json": "sha256:bc469d136c909f94d89d2816a5a4c7b08ae93380d812e837d4f1c554eae1ce2b",
         "release-notes/v0.15.3.json": "sha256:19a0074c445545468ca3cc411b21ec8bdb27be2669ae1950347cc244f6aa348c",
         "release-notes/v0.15.4.json": "sha256:6ac7fa0ef1728c27e71b2050d1b07a810f9b4b1440ccddbf28ad56e2f54d8585",
         "release-notes/v0.15.5.json": "sha256:cca1d0edd5d6fc41b512d19d98be224b990dcab41478622c11962f0fcb1bb09a",
@@ -2387,7 +2389,7 @@
         "scripts/validate-source-comment-blocks.js": "sha256:f3a8d9ef0dcf9612a694d5c005c8c05b3ffbd7e92a14a8efb4aa97f054528f7f",
         "scripts/vendor-data-gen.js": "sha256:76b627bc6e19b4a122edfca6f514bcb8ca11af02902f0957e641f503337a8a0f",
         "scripts/vendor-data-keygen.js": "sha256:94eaa4d8f832b4aac9ccbcb2a07e6b99cd35cf7b044e1412079cebdefc1f4c0e",
-        "scripts/vendor-update.sh": "sha256:c1c879ee620f064a06d776c1d330749b5128a35581352ef385fa8baf4a35f79a",
+        "scripts/vendor-update.sh": "sha256:373d7f024b7caa3345a3598fa3a586078dd842f0071e6fdad00a473f48a3a929",
         "test/00-primitives.js": "sha256:64f3a0ec3678f8b3ab401ed59cdc1139f4e8720f5ed61443a718d8f480f64d5b",
         "test/10-state.js": "sha256:7f286e00fda002ccf50ccc59d658b6dce9a4bccee304232984a932a2ceb31c49",
         "test/20-db.js": "sha256:241ef6b7ef305d077aeafb22ee3bcc75b6b549a8fa9b1a6b5d6d5fba43b48d7d",
@@ -3002,7 +3004,7 @@
         "test/layer-0-primitives/vc.test.js": "sha256:504fadbce3c8210c7ecb74e927686bdec03d7581b1dae4150c2ebefc326c182b",
         "test/layer-0-primitives/vendor-currency-classify.test.js": "sha256:a56c08cce24a600fa827756d220159365a2c3cc30428ade49df97b19466125a6",
         "test/layer-0-primitives/vendor-data.test.js": "sha256:e216ae83b187c66f1002c419e4af2701573e5743666007b564a0257332bc0c9b",
-        "test/layer-0-primitives/vendor-manifest.test.js": "sha256:55685bd11686bf76495ec29769470de05a6aaf4648d2b5722d96f213d9e32587",
+        "test/layer-0-primitives/vendor-manifest.test.js": "sha256:494f89868468618592390854903f301b4d675c1b46c11fe5117e475195731c4d",
         "test/layer-0-primitives/vex.test.js": "sha256:4a06e3e9a6ea8ffe3ab2c0af69cbe2835c1d50768c184308bb2e40638c8998cc",
         "test/layer-0-primitives/watcher.test.js": "sha256:346ef70ff89e9d4b6ba27f6a1859be0cd782b8224930c7c3d2ead5d495c08dd7",
         "test/layer-0-primitives/web-push-vapid.test.js": "sha256:4634dcf1c3fdae300b291d20473285a9d9fe2f49f9c54e4e3a2e149768d3fe32",

package/lib/vendor/blamejs/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.15.x
 
+- v0.15.20 (2026-06-24) — **Vendored SBOM version fields are derived from the bundle so they cannot drift, and the Public Suffix List + @simplewebauthn/server bundles are refreshed.** The vendor manifest recorded each bundled package's version in two scanner-facing places that were hand-maintained and could drift from the code actually shipped — the structured components[].version (the CycloneDX component versions) and the cpe string. Two had drifted: peculiar-pki's @peculiar/x509 component read 1.13.0 while the bundle shipped 2.0.0, and @noble/curves' cpe read 0.0.0 while the bundle shipped 2.2.0. A CVE scanner (Trivy / Grype / a CycloneDX export, or a consumer mirroring the manifest into its own SBOM) keys on those structured fields, so an advisory was matched against the wrong version — a false negative on a real fix or a false positive on a patched one. Both fields are corrected, the vendor-bundle script now derives them from the actually-installed package versions at bundle time so they cannot drift again, and a manifest gate fails the build if they ever disagree. Separately, the vendored Mozilla Public Suffix List is refreshed to the current upstream revision and @simplewebauthn/server is refreshed to 13.3.2. **Changed:** *Vendored Public Suffix List and @simplewebauthn/server refreshed* — The vendored Mozilla Public Suffix List is refreshed to the current upstream revision (used by b.publicSuffix for DMARC / BIMI / cookie-scope / same-site domain classification). @simplewebauthn/server is refreshed from 13.3.1 to 13.3.2, which improves WebAuthn attestation certificate-path validation; the published-tarball diff was reviewed (no install scripts, no network/eval, a self-contained code change) before re-vendoring. **Fixed:** *Vendored SBOM version metadata is bundle-derived, not hand-maintained* — lib/vendor/MANIFEST.json recorded each package's version in two places a CVE/SBOM scanner reads — the structured components[].version sub-object and the cpe string — both hand-maintained alongside the human version string, so they could (and did) drift from the bundled code. @peculiar/x509's component version read 1.13.0 while the bundle shipped 2.0.0; @noble/curves' cpe read 0.0.0 while the bundle shipped 2.2.0. Either drift makes a scanner match advisories against the wrong version. Both are corrected to the shipped versions, and the durable fix is structural: scripts/vendor-update.sh now writes both the structured component versions and the cpe version from the ACTUALLY-INSTALLED package versions captured at bundle time, so a maintainer can no longer update one field and forget the other. A smoke-time manifest gate additionally fails the build if any component or cpe version disagrees with the package version, catching a manual drift before it ships.
+
 - v0.15.19 (2026-06-22) — **Restores the wiki container build by keeping its base image on the continuously-patched rolling tag.** A follow-up to 0.15.18. The framework code is unchanged from 0.15.18 — this patch reverts one part of that release's supply-chain pass: the example wiki container's Chainguard base images had been pinned to specific digests, but Chainguard rebuilds those images continuously to ship CVE fixes, so the frozen digest fell behind an upstream fix within hours and the container's Trivy CRITICAL/HIGH release gate rejected the build (a fixed npm/undici denial-of-service the rolling tag already carried). For a deployed, Trivy-gated image, tracking the rolling, always-patched tag is the correct posture; the wiki Dockerfile is back on it. The ClusterFuzzLite fuzz base (not deployed, not release-gated) stays digest-pinned with Dependabot keeping it current. **Fixed:** *Wiki container builds again on a continuously-patched base* — 0.15.18 digest-pinned the example wiki container's Chainguard base images (runtime + builder). Because Chainguard rebuilds those images continuously to ship CVE fixes, the pinned digest went stale within hours and the container's Trivy CRITICAL/HIGH release gate rejected the build over an already-fixed npm/undici DoS (CVE-2026-12151) the rolling tag carried. The wiki Dockerfile tracks the rolling tag again, so the deployed image is always CVE-current and the build passes the release gate. To keep the Trivy-scanned image identical to the multi-arch image that is published (they are built separately), the release workflow resolves the rolling tag to a digest once at build time and feeds it to both builds via build-args — scan-equals-publish without a committed pin that goes stale. (This trades the OSSF Scorecard PinnedDependencies signal for CVE currency on a deployed, gate-scanned image — the right call here; the non-deployed ClusterFuzzLite fuzz base remains digest-pinned with Dependabot bumping it.) The framework package itself is identical to 0.15.18.
 
 - v0.15.18 (2026-06-22) — **OCSP response-freshness enforcement is restored, DPoP request-URI reconstruction peer-gates forwarded headers, and container/tool supply-chain pinning is tightened.** Three hardening fixes. The stapled-OCSP evaluator parsed each response's thisUpdate / nextUpdate with Date.parse, but those fields are already numeric (unix-ms), so Date.parse returned NaN — the freshness guard then rejected every signature-valid response, fresh or stale, with a misleading "missing thisUpdate", and the real future-dated / past-nextUpdate window checks (RFC 6960 §4.2.2.1) were unreachable dead code. b.network.tls.ocsp.evaluate / requireGood now read the numeric fields directly: a stale or future-dated response is refused and a fresh "good" response is accepted, so OCSP stapling validation works again. b.middleware.dpop reconstructed the absolute request URI — the cryptographically-bound htu — trusting X-Forwarded-Proto / X-Forwarded-Host from any caller whenever trustForwardedHeaders was set, so a direct attacker could forge the scheme or authority and make a proof signed for one origin validate against another; both now resolve through the peer-gated b.requestHelpers.trustedProtocol / trustedHost (honored only from a declared trusted-proxy peer), matching csrf-protect / security-headers / cors, and the bare trustForwardedHeaders boolean is refused. The supply-chain pass pins the wiki container and ClusterFuzzLite fuzz base images to digests (Dependabot keeps them current) and the npm-publish bundle tools to exact versions. **Added:** *b.requestHelpers.requestHost and b.requestHelpers.trustedHost* — Peer-gated request-authority resolvers — the host companions to requestProtocol / trustedProtocol. trustedHost(opts) returns { resolve(req) => string|null, peerGated }: with trustedProxies (CIDRs) X-Forwarded-Host is honored only from a trusted-proxy peer; with hostResolver(req) the operator owns it; with neither, only the request's own Host header is used and a forged X-Forwarded-Host is ignored. requestHost(req, opts?) is the low-level resolver (default Host-only; a peer predicate gates the forwarded header). For reconstructing an absolute request URL (a DPoP htu, an origin/issuer string, a redirect base) behind a proxy without trusting a forgeable header. **Changed:** *Container and bundle-tool supply-chain pinning tightened* — The wiki container's base images (cgr.dev/chainguard/node runtime + builder stages) and the ClusterFuzzLite fuzz base (gcr.io/oss-fuzz-base/base-builder-javascript) are pinned to image digests; Dependabot's docker ecosystem keeps both current, so the pin is reproducible without freezing CVE patches. The npm-publish workflow's bundle tools (esbuild, postject) are pinned to exact versions, matching CI. The OSS-Fuzz project-submission Dockerfile is intentionally left tracking the upstream base-builder, per OSS-Fuzz convention. **Security:** *OCSP response-freshness enforcement restored (RFC 6960 §4.2.2.1)* — The stapled-OCSP evaluator computed thisUpdate / nextUpdate via Date.parse(), but the parser hands those fields back as unix-ms NUMBERS (Date.UTC(...)). Date.parse() coerces its argument to a string and a bare-integer string is not a recognized date, so the result was always NaN: the !isFinite guard then rejected every signature-valid response — fresh OR stale — with a misleading "missing thisUpdate", and the genuine staleness checks (future-dated thisUpdate, past nextUpdate) sat behind it as unreachable dead code, with the stale-rejection branch latently fail-open. b.network.tls.ocsp.evaluate / requireGood now read the numeric fields directly: a stale (past-nextUpdate) or future-dated response is refused, and a fresh "good" response is accepted — OCSP stapling validation, and its replay defense, work again. · *DPoP htu reconstruction peer-gates X-Forwarded-Proto and X-Forwarded-Host* — b.middleware.dpop rebuilds the absolute request URI (scheme + authority + path) that the proof's cryptographically-bound htu claim (RFC 9449 §4.3) is verified against. When the legacy trustForwardedHeaders: true was set it derived the scheme and host from X-Forwarded-Proto / X-Forwarded-Host trusted from ANY caller, with no immediate-peer check — a direct attacker could forge X-Forwarded-Proto: https or a victim X-Forwarded-Host and make a proof signed for one origin validate against another (htu confusion). Both now resolve through the peer-gated b.requestHelpers.trustedProtocol / trustedHost, which honor the forwarded headers only when the immediate connection is a declared trusted proxy — the same fail-closed model csrf-protect (Secure cookie), security-headers (HSTS), cors (same-origin), and bot-guard (secure context) already use. A codebase-patterns detector now flags any further middleware that reads X-Forwarded-Proto / -Host directly for a scheme/authority decision. **Migration:** *DPoP: trustForwardedHeaders is replaced by trustedProxies* — b.middleware.dpop no longer honors the bare trustForwardedHeaders: true boolean — it trusted forgeable X-Forwarded-Proto / X-Forwarded-Host from any caller. Behind a reverse proxy, declare your proxy CIDRs via trustedProxies: ["10.0.0.0/8", …] (peer-gates both headers for the htu reconstruction), or own the reconstruction via protocolResolver(req) / hostResolver(req) / getHtu(req). A bare trustForwardedHeaders: true now throws at create() with that guidance. Apps not behind a proxy need no change — the default already derives the scheme from the TLS socket and the host from the request's Host header.

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

@@ -1,7 +1,7 @@
 {
   "version": 1,
-  "frameworkVersion": "0.15.19",
-  "createdAt": "2026-06-23T04:32:56.651Z",
+  "frameworkVersion": "0.15.20",
+  "createdAt": "2026-06-25T03:02:07.070Z",
   "exports": {
     "a2a": {
       "type": "object",

package/lib/vendor/blamejs/lib/vendor/MANIFEST.json

@@ -18,7 +18,7 @@
       "hashes": {
         "server": "sha256:5d539dfc9ef47121d4c09bd7256d76448a1f5ac47ee09ac44c78ff6a062af9ab"
       },
-      "refreshedAt": "2026-06-22T16:29:46.590Z"
+      "refreshedAt": "2026-06-25T02:57:00.483Z"
     },
     "@noble/curves": {
       "version": "2.2.0",
@@ -36,11 +36,11 @@
       },
       "bundler": "esbuild --format=cjs --minify --platform=node",
       "bundledAt": "2026-05-26T00:00:00Z",
-      "cpe": "cpe:2.3:a:paulmillr:noble-curves:0.0.0:*:*:*:*:node.js:*:*",
+      "cpe": "cpe:2.3:a:paulmillr:noble-curves:2.2.0:*:*:*:*:node.js:*:*",
       "hashes": {
         "server": "sha256:ebf254d5eb56aef8705a1c4af9603f47987b4870a9bb5e657e06907b701e2731"
       },
-      "refreshedAt": "2026-06-22T16:29:46.590Z"
+      "refreshedAt": "2026-06-25T02:57:00.483Z"
     },
     "@noble/post-quantum": {
       "version": "0.6.1",
@@ -71,10 +71,10 @@
       "hashes": {
         "server": "sha256:f9190309daadca4c2e2cc2b76beaa6b96e463429cc3c390bd9f0ceaf7b588c68"
       },
-      "refreshedAt": "2026-06-22T16:29:46.590Z"
+      "refreshedAt": "2026-06-25T02:57:00.483Z"
     },
     "@simplewebauthn/server": {
-      "version": "13.3.1",
+      "version": "13.3.2",
       "license": "MIT",
       "author": "Matthew Miller",
       "source": "https://github.com/MasterKale/SimpleWebAuthn",
@@ -89,12 +89,12 @@
         "server": "lib/vendor/simplewebauthn-server.cjs"
       },
       "bundler": "esbuild --format=cjs --minify --platform=node --external:crypto --external:node:crypto",
-      "bundledAt": "2026-05-27T00:00:00Z",
-      "cpe": "cpe:2.3:a:simplewebauthn:server:13.3.1:*:*:*:*:node.js:*:*",
+      "bundledAt": "2026-06-24T00:00:00Z",
+      "cpe": "cpe:2.3:a:simplewebauthn:server:13.3.2:*:*:*:*:node.js:*:*",
       "hashes": {
-        "server": "sha256:f359a782ac57e3ff56ac71083d17f5c082f88ab49d645fc2bede398b47adebdb"
+        "server": "sha256:49411d893f5e9b0e2fcaa564b4ec7921f73a9a06229b5e53d49c1453ea1a365c"
       },
-      "refreshedAt": "2026-06-22T16:29:46.590Z"
+      "refreshedAt": "2026-06-25T02:57:00.483Z"
     },
     "SecLists-common-passwords-top-10000": {
       "version": "10k-most-common (master)",
@@ -114,7 +114,7 @@
       },
       "runtime_artifact": "lib/vendor/common-passwords-top-10000.data.js",
       "integrity_layers": "sha256 + sha3-512 + SLH-DSA-SHAKE-256f signature + in-payload canary (where applicable)",
-      "refreshedAt": "2026-06-22T16:29:46.590Z"
+      "refreshedAt": "2026-06-25T02:57:00.483Z"
     },
     "bimi-trust-anchors": {
       "version": "operator-managed",
@@ -139,7 +139,7 @@
       },
       "runtime_artifact": "lib/vendor/bimi-trust-anchors.data.js",
       "integrity_layers": "sha256 + sha3-512 + SLH-DSA-SHAKE-256f signature + in-payload canary (where applicable)",
-      "refreshedAt": "2026-06-22T16:29:46.590Z"
+      "refreshedAt": "2026-06-25T02:57:00.483Z"
     },
     "publicsuffix-list": {
       "version": "master",
@@ -152,14 +152,14 @@
         "data_js": "lib/vendor/public-suffix-list.data.js"
       },
       "bundler": "curl https://publicsuffix.org/list/public_suffix_list.dat",
-      "bundledAt": "2026-06-22T00:00:00Z",
+      "bundledAt": "2026-06-24T00:00:00Z",
       "hashes": {
-        "server": "sha256:0adddeb62057d8d40799dffb29fe14f65dd009259afe02eb2f0b4602b791aae6",
-        "data_js": "sha256:82af512cacf0fd2c60925e63f877b69477b1b2f7bb5af698fd862af61369902e"
+        "server": "sha256:42c4f3544726fa2feb4f304c889c5e391feb5d28080c9b6356ff82e267a93706",
+        "data_js": "sha256:c840d9ae5c6bf4a07967340a5c649df2c6a66a287db41e408461c46cc32348e6"
       },
       "runtime_artifact": "lib/vendor/public-suffix-list.data.js",
       "integrity_layers": "sha256 + sha3-512 + SLH-DSA-SHAKE-256f signature + in-payload canary (where applicable)",
-      "refreshedAt": "2026-06-22T16:29:46.590Z"
+      "refreshedAt": "2026-06-25T02:57:00.483Z"
     },
     "peculiar-pki": {
       "version": "2.0.0+pkijs-3.4.0",
@@ -170,7 +170,7 @@
       "components": {
         "@peculiar/x509": {
           "url": "https://github.com/PeculiarVentures/x509",
-          "version": "1.13.0"
+          "version": "2.0.0"
         },
         "pkijs": {
           "url": "https://github.com/PeculiarVentures/PKI.js",
@@ -190,7 +190,7 @@
       "hashes": {
         "server": "sha256:9bbc191afaaa2b1e5757f00480457c08134cdc2c55d541df18d9155bba9cbf77"
       },
-      "refreshedAt": "2026-06-22T16:29:46.590Z"
+      "refreshedAt": "2026-06-25T02:57:00.483Z"
     }
   }
 }

package/lib/vendor/blamejs/lib/vendor/public-suffix-list.dat

@@ -5,8 +5,8 @@
 // Please pull this list from, and only from https://publicsuffix.org/list/public_suffix_list.dat,
 // rather than any other VCS sites. Pulling from any other URL is not guaranteed to be supported.
 
-// VERSION: 2026-06-22_11-46-12_UTC
-// COMMIT: 27a7b5d881b91def306422e6cc243f05c49f3a58
+// VERSION: 2026-06-24_06-18-09_UTC
+// COMMIT: 18ecca5d54471f21918798da451dd8d03a18f3c7
 
 // Instructions on pulling and using this list can be found at https://publicsuffix.org/list/.
 
@@ -12976,9 +12976,22 @@ cc.cd
 us.ci
 de5.net
 
-// DNShome : https://www.dnshome.de/
+// dnsHome : https://www.dnshome.de/
 // Submitted by Norbert Auler <mail@dnshome.de>
+dnshome.at
+resolve.bar
+ddns.berlin
+dnshome.cloud
+ddnssec.de
 dnshome.de
+dyndnssec.de
+heimdns.de
+srvdns.de
+dnshome.eu
+dnshome.it
+dyn.now
+heimdns.online
+ddns.wtf
 
 // DotArai : https://www.dotarai.com/
 // Submitted by Atsadawat Netcharadsang <atsadawat@dotarai.co.th>
@@ -15258,6 +15271,12 @@ nyc.mn
 // Submitted by Kor Nielsen <kor@pubtls.org>
 pubtls.org
 
+// Puter : https://puter.com
+// Submitted by Puter Security Team <security@puter.com>
+puter.app
+puter.site
+puter.work
+
 // PythonAnywhere LLP : https://www.pythonanywhere.com
 // Submitted by Giles Thomas <giles@pythonanywhere.com>
 pythonanywhere.com