@blamejs/blamejs-shop 0.4.87 → 0.4.89

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- 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.
+
 - v0.4.87 (2026-06-22) — **Adding a bundle now charges the advertised bundle price even when a member item is already in the cart.** Fixes a pricing bug when adding a product bundle to a cart that already contains one of the bundle's items. Adding a bundle allocates the discounted bundle price across its members and writes each member to the cart at its allocated per-unit price. But when a member variant was already in the cart on its own, the add merged into the existing line and kept that line's standalone list price, so the cart subtotal came out above the advertised bundle price — the shopper was quoted the discounted bundle but charged closer to the full sum of parts. Adding a bundle now adds the bundle's units at the bundle price while preserving any units already in the cart: a fresh bundle add realizes exactly the advertised bundle price, and a bundle added on top of a standalone item keeps that item and adds the bundle at its discounted price (rather than dropping the item or extending the discount to it). No configuration changes; upgrade to pick it up. **Fixed:** *Bundle add honors the bundle price without disturbing existing cart units* — Adding a bundle now adds each member's units at the bundle's allocated per-unit price. On a fresh line the realized subtotal is exactly the advertised bundle price. When the variant is already in the cart, its existing units are kept at their value and the bundle's units are added at the bundle price, so the shopper is neither overcharged (the previous behavior charged the standalone list price for the bundle unit) nor has their existing quantity dropped. Adding the same bundle twice adds two bundles' worth of units. Direct add-to-cart of a standalone item is unchanged.
 
 - v0.4.86 (2026-06-22) — **Failed outbound webhook deliveries are now retried automatically on the backoff schedule, not only by a manual click.** Restores the automatic retry guarantee for outbound webhooks. When an order-lifecycle or low-stock delivery to a subscriber endpoint fails, the delivery already records its next retry time and walks a backoff schedule toward the dead-letter queue — but nothing was ever driving those retries, so a delivery only re-attempted when an operator hand-clicked retry in the admin console. A briefly-unreachable receiver (a deploy, a load-balancer reload) therefore lost every event in the gap. A scheduled tick now re-attempts every due delivery once a minute, so a failed delivery is retried automatically — at one minute, five minutes, thirty minutes, four hours, then a day — until it succeeds or lands in the dead-letter queue, with no manual intervention. The manual retry remains available as an immediate override. No configuration changes; upgrade to pick it up. **Fixed:** *Outbound webhook retries now run automatically* — A scheduled retry pass re-attempts every delivery whose backoff has come due, advancing it through the retry schedule to success or to the dead-letter queue without an operator click. Each delivery is claimed atomically before it is attempted, so two overlapping passes can never re-send the same delivery twice, and a receiver that recovers within the backoff window now receives the events it missed. An operator can still force an immediate retry from the admin console. **Security:** *Bundled framework refreshed to blamejs 0.15.16* — Picks up a broad fail-closed and resource-exhaustion hardening pass that rides inside the composed primitives: a present-but-unparseable timestamp on a credential or certificate verifier (DKIM, ARC, SAML NotBefore, FIDO/BIMI/S-MIME validity windows) now refuses the credential instead of silently skipping the check; DMARC refuses a record with no usable policy rather than defaulting a failing message to delivery; outbound clients enforce an overall wall-clock timeout (not only an idle timer) so a byte-trickling peer can no longer hold a request open indefinitely; DNS lookups gain a default deadline; and append-only log sinks refuse a symlinked path. No configuration changes.

package/SECURITY.md

@@ -59,6 +59,14 @@ cosign verify-blob sbom.cdx.json \
   --certificate-oidc-issuer 'https://token.actions.githubusercontent.com'
 ```
 
+`sbom.vendored.cdx.json` is committed to the repository and generated
+as a deterministic projection of `lib/vendor/MANIFEST.json`. The vendor
+refresh regenerates it, and a build gate (`build-vendored-sbom.js
+--check`) fails if it drifts from the vendored manifest, so the signed
+SBOM you verify is byte-reproducible from the committed source — its
+component versions can never silently fall behind what ships under
+`lib/vendor/`.
+
 ### 4. Byte digests + ML-DSA-65 signature (PQC-first)
 
 The release tarball ships with three digest / signature sidecars
@@ -311,15 +319,20 @@ node -e "
   (success / failure / denied) and paginated. Opening the log is itself
   recorded (an `audit.read` row), so reviewing the audit trail leaves
   its own forensic mark.
-- **The gift-card ledger is hash-chained, fork-proof, and verifiable.**
-  Every ledger entry — credits, debits, and expirations alike — links to
-  its predecessor through a per-card SHA3-512 chain, so a direct edit or
-  deletion of a row breaks the linkage. A uniqueness fence (one child per
-  chain tip) makes concurrent writes serialize rather than fork the
-  chain, and `giftCardLedger.verifyChain(cardId)` recomputes a card's
-  chain end to end and reports the first divergence — run it whenever a
-  card's balance is disputed. The overdraft refusal stays inside the same
-  guarded insert, so the integrity device never weakens the balance gate.
+- **The gift-card and store-credit ledgers are hash-chained, fork-proof,
+  and verifiable.** Every ledger entry — credits, debits, and
+  expirations alike — links to its predecessor through a SHA3-512 chain,
+  keyed per card (gift cards) or per customer (store credit), so editing a
+  row or deleting one from the middle breaks the linkage. A uniqueness
+  fence (one child per chain tip) makes concurrent writes serialize rather
+  than fork the chain. `giftCardLedger.verifyChain(cardId)` /
+  `storeCredit.verifyChain(customerId)` recompute a ledger's chain end to
+  end and report the first divergence — run them whenever a balance is
+  disputed; pass a trusted anchor (a row count + head hash from an earlier
+  snapshot) to also catch a truncation that deletes the most-recent rows,
+  which an append-only chain can't detect on its own. The overdraft
+  refusal stays inside the same guarded insert, so the integrity device
+  never weakens the balance gate.
 - **Privacy exports hold the whole record; erasure states a basis per
   domain.** A subject-access export walks every table that keys a row
   by the customer — identity, orders, subscriptions, addresses, saved

package/lib/asset-manifest.json

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

package/lib/gift-card-ledger.js

@@ -242,15 +242,14 @@ function create(opts) {
   }
 
   // How many times a writer re-derives the chain tip when the parent fence
-  // refuses its INSERT (another write landed first). Each retry re-reads
-  // the tip, so contention resolves in one extra round trip per racing
-  // writer; five attempts is far beyond any realistic burst.
-  var CHAIN_WRITE_ATTEMPTS = 5;
-
-  function _isChainFenceCollision(err) {
-    var msg = (err && err.message) || "";
-    return /UNIQUE constraint failed/i.test(msg) && /(prev_hash|chain_parent)/i.test(msg);
-  }
+  // refuses its INSERT (another write landed first). Each fence round lets
+  // exactly ONE racing writer win, so a burst of N concurrent writes to the
+  // SAME card needs up to N rounds — the cap is sized well beyond any
+  // realistic same-card fan-in so a legitimate burst is never dropped with
+  // GIFT_CARD_LEDGER_CONTENTION. A genuine non-collision insert error
+  // re-throws on the first attempt (see _attemptChainedWrite), so a high cap
+  // never spins on a real failure.
+  var CHAIN_WRITE_ATTEMPTS = 64;
 
   // One fenced write attempt against a tip the caller just read. EVERY
   // event kind writes through here so every row participates in the
@@ -295,7 +294,16 @@ function create(opts) {
       if (Number(res.rowCount || 0) === 0) return { refused: true };
       return { written: { id: id, balance_after_minor: d.after, occurred_at: d.ts } };
     } catch (e) {
-      if (_isChainFenceCollision(e)) return { collided: true };
+      // State-agnostic collision detection — never error-message matching:
+      // the production D1 service-binding redacts the SQLite "UNIQUE
+      // constraint failed" text to a generic "HTTP 500", so a message regex
+      // is blind in prod (it would only match under node:sqlite, where the
+      // full text survives). Re-read the tip — if it advanced past the
+      // parent we tried to chain off, a competing write claimed our slot (a
+      // genuine fence collision) and we retry; if the tip is unchanged the
+      // insert failed for another reason, so re-throw.
+      var after = await _readLatest(giftCardId);
+      if (after.row_hash !== latest.row_hash) return { collided: true };
       throw e;
     }
   }
@@ -483,8 +491,26 @@ function create(opts) {
     // leaves behind) fails: an all-NULL chain is unanchored, not valid.
     // An empty ledger (zero rows) is the only no-anchor case that passes.
     // O(n) per card; operator-audit use, not hot-path.
-    verifyChain: async function (giftCardId) {
+    verifyChain: async function (giftCardId, opts) {
       _uuid(giftCardId, "gift_card_id");
+      opts = opts || {};
+      // Optional trusted anchor (opts.anchor = { count, head } from a prior
+      // snapshot's total_rows + last_hash) — the ONLY way to detect a TAIL
+      // TRUNCATION or whole-chain replacement, since an append-only chain
+      // stays internally consistent after its tail is removed. The row at the
+      // snapshot's position must still carry the snapshot's head hash (it
+      // survives later valid appends). Without an anchor, truncation is not
+      // ruled out and anchor_checked:false is reported (operator-audit-log
+      // closes the same gap with signed checkpoints).
+      var anchor = null;
+      if (opts.anchor != null) {
+        if (typeof opts.anchor !== "object"
+            || typeof opts.anchor.count !== "number" || !Number.isInteger(opts.anchor.count) || opts.anchor.count < 1
+            || typeof opts.anchor.head !== "string" || opts.anchor.head.length !== SHA3_512_HEX_LEN) {
+          throw new TypeError("giftCardLedger.verifyChain: anchor must be { count: positive integer, head: " + SHA3_512_HEX_LEN + "-hex-char string }");
+        }
+        anchor = opts.anchor;
+      }
       var r = await query(
         "SELECT * FROM gift_card_ledger WHERE gift_card_id = ?1 " +
         "ORDER BY occurred_at ASC, id ASC",
@@ -551,11 +577,42 @@ function create(opts) {
           reason:         "unanchored chain (no hashed row in a populated ledger)",
         };
       }
+      // Internal walk is clean. With a trusted anchor, also rule out a tail
+      // truncation below the snapshot: the row at the snapshot's position
+      // must still carry the snapshot's head hash, and the chain must not be
+      // shorter than the snapshot.
+      if (anchor) {
+        if (rows.length < anchor.count) {
+          return {
+            ok:             false,
+            rows_verified:  rows.length - legacyPrefix,
+            legacy_prefix:  legacyPrefix,
+            anchor_checked: true,
+            reason:         "row count below anchor (possible tail truncation)",
+            expected_count: anchor.count,
+            actual_count:   rows.length,
+          };
+        }
+        var anchorRow = rows[anchor.count - 1];
+        if (!anchorRow || anchorRow.row_hash !== anchor.head) {
+          return {
+            ok:             false,
+            rows_verified:  rows.length - legacyPrefix,
+            legacy_prefix:  legacyPrefix,
+            anchor_checked: true,
+            reason:         "anchor row hash mismatch (possible tail truncation or divergence)",
+            expected:       anchor.head,
+            actual:         anchorRow ? anchorRow.row_hash : null,
+          };
+        }
+      }
       return {
-        ok:            true,
-        rows_verified: rows.length - legacyPrefix,
-        legacy_prefix: legacyPrefix,
-        last_hash:     prevHash,
+        ok:             true,
+        rows_verified:  rows.length - legacyPrefix,
+        legacy_prefix:  legacyPrefix,
+        total_rows:     rows.length,
+        last_hash:      prevHash,
+        anchor_checked: anchor != null,
       };
     },