@blamejs/blamejs-shop 0.4.30 → 0.4.32

package/lib/vendor/blamejs/lib/consent.js

@@ -46,6 +46,8 @@ var cluster = require("./cluster");
 var clusterStorage = require("./cluster-storage");
 var chainWriter = require("./chain-writer");
 var safeAsync = require("./safe-async");
+var safeSql = require("./safe-sql");
+var sql = require("./sql");
 var lazyRequire = require("./lazy-require");
 var C = require("./constants");
 var { ClusterError } = require("./framework-error");
@@ -300,14 +302,24 @@ function isGranted(opts) {
   }
   // Find the most recent consent row for this (subjectId, purpose).
   // subjectId is sealed → look up via subjectIdHash (derived).
-  var hash = db().hashFor("consent_log", "subjectId", opts.subjectId);
-  if (!hash) {
+  var subjectCand = db().hashCandidatesFor("consent_log", "subjectId", opts.subjectId);
+  if (!subjectCand) {
     throw new Error("consent_log subjectId is missing a derived hash — schema misconfigured");
   }
-  var row = db().prepare(
-    "SELECT action FROM consent_log WHERE subjectIdHash = ? AND purpose = ? " +
-    "ORDER BY monotonicCounter DESC LIMIT 1"
-  ).get(hash, opts.purpose);
+  // Local db() handle: emit the LOCAL table name (consent_log) quoted so
+  // the camelCase subjectIdHash / monotonicCounter columns resolve, and
+  // run the built { sql, params } against the prepared statement. whereIn
+  // dual-reads across the keyed-MAC flip so a row written under the legacy
+  // salted-sha3 subjectIdHash is still matched.
+  var isGrantedBuilt = sql.select("consent_log", { dialect: "sqlite", quoteName: true })
+    .columns(["action"])
+    .whereIn("subjectIdHash", subjectCand.values)
+    .where("purpose", opts.purpose)
+    .orderBy("monotonicCounter", "desc")
+    .limit(1)
+    .toSql();
+  var isGrantedStmt = db().prepare(isGrantedBuilt.sql);
+  var row = isGrantedStmt.get.apply(isGrantedStmt, isGrantedBuilt.params);
   if (!row) return false;
   return row.action === "granted";
 }
@@ -334,12 +346,14 @@ function isGranted(opts) {
  */
 function history(subjectId) {
   if (!subjectId) throw new Error("consent.history requires a subjectId");
-  var hash = db().hashFor("consent_log", "subjectId", subjectId);
-  if (!hash) {
+  var subjectCand = db().hashCandidatesFor("consent_log", "subjectId", subjectId);
+  if (!subjectCand) {
     throw new Error("consent_log subjectId is missing a derived hash — schema misconfigured");
   }
+  // whereIn dual-reads across the keyed-MAC flip so the subject's pre-flip
+  // (legacy salted-sha3) consent rows still appear in the access response.
   var rows = db().from("consent_log")
-    .where({ subjectIdHash: hash })
+    .whereIn(subjectCand.field, subjectCand.values)
     .orderBy("monotonicCounter", "asc")
     .all();
   return rows;
@@ -409,30 +423,69 @@ async function _appendConsentRow(fields) {
 }
 
 async function _upsertConsentTip(counter, rowHash, signedAt, fencingToken) {
-  // Single atomic INSERT … ON CONFLICT DO UPDATE … WHERE … RETURNING.
-  // Same canonical fencing-token guard as _blamejs_audit_tip: the
-  // WHERE clause enforces monotonic-non-decreasing fencingToken at
-  // the DB level so a partitioned old leader can't overwrite the tip
-  // even if its application-layer cluster.requireLeader() gate let
-  // the call through.
+  // Single atomic INSERT … ON CONFLICT(scope) DO UPDATE … WHERE … RETURNING
+  // via b.sql. Same canonical fencing-token guard as _blamejs_audit_tip: the
+  // fenced WHERE enforces monotonic-non-decreasing fencingToken at the DB
+  // level so a partitioned old leader can't overwrite the tip even if its
+  // application-layer cluster.requireLeader() gate let the call through. On
+  // rejection RETURNING produces 0 rows.
+  //
+  // The consent-tip is external-only; its LOGICAL name IS the
+  // `_blamejs_`-prefixed name (self-mapped in LOCAL_TO_EXTERNAL), passed
+  // bare to b.sql so clusterStorage rewrites it (and the same bare name
+  // inside the guarded fence) to the configured prefix and placeholderizes.
+  //
+  // Dialect is the ACTIVE backend (clusterStorage.dialect()) so the fence's
+  // identifier quoting + conflict-expression idiom match the server the SQL
+  // dispatches to. The fence text itself is dialect-specific because the
+  // builder folds it verbatim: on Postgres / SQLite the upsert keeps a
+  // `WHERE "<table>"."fencingToken" <= EXCLUDED."fencingToken"` guard (and a
+  // RETURNING row that signals fenced-out via 0 rows); on MySQL there is no
+  // WHERE and no EXCLUDED, so the builder folds the same guard into per-column
+  // `IF(<table>.`fencingToken` <= VALUES(`fencingToken`), VALUES(col), col)`
+  // — the fence must therefore reference `VALUES(...)` with backticks. The
+  // bare table qualifier (no quoteName) lets clusterStorage rewrite the
+  // logical `_blamejs_consent_tip` to the configured prefix inside the fence
+  // exactly as it does for the table name.
+  var d = clusterStorage.dialect();
+  var qFence = safeSql.quoteIdentifier("fencingToken", d);
+  var tipFence = d === "mysql"
+    ? "_blamejs_consent_tip." + qFence + " <= VALUES(" + qFence + ")"     // allow:hand-rolled-sql — bare logical name for clusterStorage rewrite
+    : "_blamejs_consent_tip." + qFence + " <= EXCLUDED." + qFence;        // allow:hand-rolled-sql — bare logical name for clusterStorage rewrite
+  var tipBuilt = sql.upsert("_blamejs_consent_tip", { dialect: d })   // allow:hand-rolled-sql — bare logical name for clusterStorage rewrite
+    .columns(["scope", "atMonotonicCounter", "rowHash", "signedAt", "fencingToken"])
+    .values({
+      scope:              "consent",
+      atMonotonicCounter: counter,
+      rowHash:            rowHash,
+      signedAt:           signedAt,
+      fencingToken:       fencingToken,
+    })
+    .onConflict(["scope"])
+    .doUpdateFromExcluded(["atMonotonicCounter", "rowHash", "signedAt", "fencingToken"])
+    // guardColumn pins fencingToken LAST in the MySQL SET list so every
+    // other column's IF() evaluates the guard against the PRE-UPDATE token
+    // (MySQL evaluates SET left-to-right; a later assignment would otherwise
+    // see fencingToken already overwritten). Ignored on Postgres / SQLite,
+    // which apply the WHERE atomically.
+    .conflictWhere(tipFence, [], { guardColumn: "fencingToken" })
+    .returning(["fencingToken"])
+    .toSql();
   var result = await safeAsync.withTimeout(
-    clusterStorage.execute(
-      "INSERT INTO _blamejs_consent_tip " +
-      "  (scope, atMonotonicCounter, rowHash, signedAt, fencingToken) " +
-      "VALUES ('consent', ?, ?, ?, ?) " +
-      "ON CONFLICT (scope) DO UPDATE SET " +
-      "  atMonotonicCounter = EXCLUDED.atMonotonicCounter, " +
-      "  rowHash            = EXCLUDED.rowHash, " +
-      "  signedAt           = EXCLUDED.signedAt, " +
-      "  fencingToken       = EXCLUDED.fencingToken " +
-      "WHERE _blamejs_consent_tip.fencingToken <= EXCLUDED.fencingToken " +
-      "RETURNING fencingToken",
-      [counter, rowHash, signedAt, fencingToken]
-    ),
+    clusterStorage.execute(tipBuilt.sql, tipBuilt.params),
     FRAMEWORK_SQL_TIMEOUT_MS,
     { name: "consent.upsertConsentTip" }
   );
-  if (!result.rows || result.rows.length === 0) {
+  // MySQL upsert has no RETURNING — the builder emits a readback SELECT
+  // alongside, but a fenced-out lower-token write still SUCCEEDS as a no-op
+  // INSERT…ON DUPLICATE KEY UPDATE (the IF() keeps the stored values), so
+  // there is no 0-rows signal to detect. The DB-level fence still PRESERVES
+  // the tip (the security property); the FENCED_OUT throw is the
+  // Postgres/SQLite RETURNING-0-rows path only. On MySQL clusterStorage is
+  // not a supported framework backend, so the consent-tip never dispatches
+  // there in production — the threaded dialect makes the SAME builders emit
+  // valid MySQL for operators driving these shapes against MySQL directly.
+  if (d !== "mysql" && (!result.rows || result.rows.length === 0)) {
     throw new ClusterError(
       "FENCED_OUT",
       "consent-tip update rejected: incoming fencingToken=" + fencingToken +

package/lib/vendor/blamejs/lib/constants.js

@@ -156,22 +156,27 @@ var PQC_GROUPS = Object.freeze({
   SecP384r1MLKEM1024:    0x11ED,
 });
 
-// Highest-first preference list. Node TLS picks the first mutually-
-// supported group during the handshake, so SecP384r1MLKEM1024
-// (P-384 + ML-KEM-1024) is what we always use when the peer also
-// advertises it. X25519MLKEM768 is the only fallback — both are
-// PQC hybrids with current standardized parameter sets.
+// Highest-first preference list for OUTBOUND TLS (clients only — the
+// server's accept-groups are configured separately). Node TLS picks the
+// first mutually-supported group during the handshake, so a peer that
+// advertises SecP384r1MLKEM1024 (P-384 + ML-KEM-1024) gets it, then the
+// X25519 / SecP256r1 ML-KEM hybrids. X25519 (classical) is the LAST-RESORT
+// fallback for peers that support no ML-KEM hybrid yet — still most of the
+// public TLS surface in 2026 (webhooks, OAuth/OIDC, ACME, third-party APIs).
 //
-// Weaker hybrids (e.g. P-256 + ML-KEM-768) are deliberately excluded
-// from the framework's default preference. An operator integrating
-// with a peer that only supports a weaker PQC group constructs their
-// own https.Agent outside lib/pqc-agent so the downgrade is visible
-// in the diff — the framework primitive cannot be coaxed into
-// negotiating below this list.
+// The framework always PREFERS a hybrid on every handshake; classical
+// X25519 is only negotiated when the peer offers none of the hybrids. When
+// a connection lands on classical instead, the outbound path emits a
+// `tls.classical_downgrade` audit event (lib/pqc-agent.js) so operators can
+// see which peers forced a non-PQC negotiation and track their
+// dependencies' PQC readiness. Weaker non-hybrid classical groups
+// (P-256 / P-384) are deliberately NOT offered — the fallback floor is the
+// X25519 group.
 var TLS_GROUP_PREFERENCE = Object.freeze([
   "SecP384r1MLKEM1024",
   "X25519MLKEM768",
   "SecP256r1MLKEM768",
+  "X25519",
 ]);
 
 var TLS_GROUP_CURVE_STR = TLS_GROUP_PREFERENCE.join(":");
@@ -179,6 +184,16 @@ var TLS_GROUP_CURVE_STR = TLS_GROUP_PREFERENCE.join(":");
 // ---- Vault sealed-value prefix ----
 var VAULT_PREFIX = "vault:";
 
+// ---- Per-row-key sealed-column prefix ----
+// Columns encrypted under a row-scoped key (K_row) — distinct from the
+// vault-root `vault:` / AAD-bound `vault.aad:` prefixes so the read path
+// can route a cell to its decrypt: K_row-sealed cells unwrap the row's
+// secret from `_blamejs_per_row_keys`, derive K_row, then decrypt under
+// it (XChaCha20-Poly1305, AEAD-bound to (table, rowId, column,
+// schemaVersion)). Destroying the row's wrapped secret leaves these
+// cells mathematically undecryptable — the crypto-shred substrate.
+var ROW_PREFIX = "vault.row:";
+
 // ---- Default hash namespaces for derived-hash indexed lookups ----
 // Apps add their own via app-config registries. The 'bj-' namespace
 // prevents collision between framework-derived and app-derived hashes.
@@ -205,5 +220,6 @@ module.exports = {
   TLS_GROUP_PREFERENCE:   TLS_GROUP_PREFERENCE,
   TLS_GROUP_CURVE_STR:    TLS_GROUP_CURVE_STR,
   VAULT_PREFIX:           VAULT_PREFIX,
+  ROW_PREFIX:             ROW_PREFIX,
   HASH_PREFIX:            HASH_PREFIX,
 };