Gate the bundler route at the edge, not p4; revert the write-gate subject rule

Author: jim-toth

ao/runtime/write-gate.lua

@@ -85,88 +85,6 @@ function gate.configuredIds(base)
   return out
 end
 
---- The node's OWN uploads arrive with an UNSIGNED ENVELOPE.
----
---- `dev_arweave:post_tx/4`'s `ans104@1.0` clause posts
----   hb_http:post(<bundler-ans104>, #{ path, `bundler-subject` = `body`, body = <the item> })
---- and `hb_http:post` never commits what it sends — there is no `hb_message:commit` anywhere on
---- the outbound request path. The signature rides on the nested item, which is precisely what
---- `bundler-subject` tells `dev_bundler:verify_message` to check INSTEAD of the envelope. Measured
---- shape of `req.request` for one of these:
----
----   Message < Path: /~bundler@1.0/tx > {
----     commitments      (absent — the envelope is unsigned)
----     bundler-subject => `body`
----     body            => the SIGNED item, with its own commitments and a `target` or `process`
----   }
----
---- So a scheduler upload reaches p4 unsigned. `dev_faff` admits it (`lists:all` over an empty
---- signer list is vacuously true) and this gate's `n == 0` rule refuses it. That asymmetry is why
---- self-bundling worked on dev and silently stopped publishing on stage and live: the scheduler
---- DISCARDS the upload result (`dev_scheduler_server.erl:266-269`), so a refusal is dropped and
---- never retried and the slot's assignment never reaches Arweave. Eight stage slots were lost
---- that way on 2026-08-27 before it was reverted.
----
---- ⚠️ This is the SECOND of two independent causes, and it was invisible until the first was
---- fixed. Before hyperbeam-docker patch 0005, `dev_lua` could not encode a cache link, so the
---- request never reached this function at all and every gate variant failed identically. Both
---- fixes are required; neither alone is enough.
----
---- ⚠️ This does NOT weaken the gate, and specifically it is not the forbidden shortcut of putting
---- `^/~bundler@1.0` in `p4-non-chargable-routes`. The subject is judged by exactly the same rule
---- as a write: our own wallets, or an address the target contract already admits. An unsigned
---- subject still refuses, and a stranger's signed item names no gated target and refuses too.
----
---- Asserted by scripts/probe/gated-bundler-repro.ts, which runs locally and costs no slots.
---- 🚨 Is this the bundler route? The subject rule below MUST NOT apply anywhere else.
----
---- A `committer` is a FIELD, not a signature check. Whether it can be trusted depends on who
---- verified the message before p4 ran, and that is codec-dependent
---- (`hb_http:req_to_tabm_singleton`): `ans104@1.0` is verified unconditionally by
---- `ar_bundles:verify_item`, `tx@1.0` by `ar_tx:verify`, any other codec by `hb_message:verify`
---- — but `httpsig@1.0` is verified ONLY when `force_signed_requests` is set, and it is not set on
---- any of our nodes (checked on stage and live: absent, so upstream's `false`).
----
---- The bundler envelope is unsigned httpsig, so its nested subject's `committer` is UNVERIFIED
---- data at this point. Without this path check, anyone could put `bundler-subject` on an unsigned
---- httpsig POST to `/<pid>~process@1.0/push`, declare a `committer` of one of our deploy wallets
---- in the body, and be admitted — consuming the slot the gate exists to protect.
----
---- Confined to `~bundler@1.0`, a forged subject buys nothing: the request reaches `dev_bundler`,
---- whose own `verify_message` checks the subject's signature properly and rejects it, and no slot
---- is created and no AR is spent on that path. The gate is still the cost filter; the bundler is
---- the authority for what it bundles, exactly as each contract's ACL is for what it accepts.
----
---- Prefix-compared with `string.sub`, no pattern engine — same reasoning as `targetOf`.
-function gate.isBundlerPath(path)
-  if type(path) ~= 'string' then return false end
-  local want = '/~bundler@1.0/'
-  if string.sub(path, 1, #want) == want then return true end
-  -- Some callers present the path without its leading slash.
-  return string.sub(path, 1, #want - 1) == string.sub(want, 2)
-end
-
-function gate.subjectOf(m)
-  if type(m) ~= 'table' then return nil end
-  local key = m['bundler-subject']
-  if type(key) ~= 'string' or key == '' then return nil end
-  local subject = m[key]
-  if type(subject) ~= 'table' then return nil end
-  return subject
-end
-
---- Which gated contract is this SUBJECT aimed at? An assignment names it in `process`, a message
---- in `target`. There is nothing to prefix-match as there is for a path: the value either IS one
---- of our ids or it is not.
-function gate.subjectTargetOf(subject, ids)
-  if type(subject) ~= 'table' then return nil end
-  local p = subject.process
-  if type(p) == 'string' and ids[p] then return p end
-  local t = subject.target
-  if type(t) == 'string' and ids[t] then return t end
-  return nil
-end
-
 --- Which gated contract is this request writing to?
 ---
 --- Matched as a PREFIX (`/<id>~process@1.0`), not a substring: an id appearing anywhere else in
@@ -244,15 +162,6 @@ function estimate(base, req, opts)
   local request = type(req) == 'table' and req.request or nil
   local signers, n = gate.committersOf(request)
 
-  -- An unsigned ENVELOPE is not the same thing as an unsigned request. The bundler route carries
-  -- its signature on the subject the envelope names, so look there before refusing — otherwise the
-  -- node's own uploads are refused and their assignments are lost silently.
-  local subject = nil
-  if n == 0 and gate.isBundlerPath(request and (request.path or request['request-path'])) then
-    subject = gate.subjectOf(request)
-    if subject ~= nil then signers, n = gate.committersOf(subject) end
-  end
-
   -- Deny-by-default on unsigned. Deliberately stricter than dev_faff, whose `lists:all` over an
   -- empty signer list is vacuously true — stock faff ADMITS unsigned requests.
   if n == 0 then return 'ok', REFUSE end
@@ -263,15 +172,8 @@ function estimate(base, req, opts)
   for i = 1, n do if not deploy[signers[i]] then allDeploy = false end end
   if allDeploy then return 'ok', ADMIT end
 
-  -- A bundler POST's path is `/~bundler@1.0/tx` and names no contract, so the target has to come
-  -- from the subject. Everything else is still matched on the path.
   local ids = gate.configuredIds(base)
-  local pid
-  if subject ~= nil then
-    pid = gate.subjectTargetOf(subject, ids)
-  else
-    pid = gate.targetOf(request and (request.path or request['request-path']), ids)
-  end
+  local pid = gate.targetOf(request and (request.path or request['request-path']), ids)
   if not pid then return 'ok', REFUSE end
 
   local opreg = base and base['operator-registry']

ao/scripts/probe/gated-bundler-repro.ts

@@ -127,6 +127,10 @@ const writeConfig = (opts: {
       { template: '^/~meta@1.0' },
       { template: '^/~hyperbuddy@1.0' },
       { template: '^/~query@1.0' },
+      // Mirrors stage and live: the bundler route is exempt from pricing, and the EDGE is what
+      // keeps it off the internet. Legitimate only because those edges refuse `~bundler@1.0`;
+      // dev, whose edge is open, keeps p4 in front of it instead.
+      { template: '^/~bundler@1.0/(tx|item)$' },
     ],
     'rate-limit-requests': 100000,
     'rate-limit-max': 100000,

ao/scripts/probe/p4-gate-e2e.ts

@@ -110,6 +110,12 @@ const writeConfig = (gatedPids: string[], opreg = '', gateModuleId = '', deployW
       { template: '^/~meta@1.0' },
       { template: '^/~hyperbuddy@1.0' },
       { template: '^/~query@1.0' },
+      // NO bundler carve-out here, deliberately, even though stage and live have one. That
+      // carve-out is only safe because those edges refuse `~bundler@1.0` outright, and this
+      // probe's node has no edge at all — so p4 must stay in front of the bundler, exactly as it
+      // does on dev. Mirroring production here was tried and `verify-access-policy` correctly
+      // failed it twice over: the carve-out was unpaired, and a stranger's item was accepted.
+      // See scripts/probe/gated-bundler-repro.ts, which does carry it, for the reasoning.
     ],
     'rate-limit-requests': 100000, 'rate-limit-max': 100000, 'rate-limit-period': 60,
     // faff is still the LEDGER device; its list governs everything the gate does not.

ao/scripts/verify-access-policy.ts

@@ -288,14 +288,29 @@ for (const env of targets) {
     }), 'deploy-wallets is non-empty and EIP-55, excluding the node self-entry (spawns are impossible without it)',
       `${dwEvm.length} entries${dwSelf.length ? ' + node self-entry' : ''}`)
 
-    // Assert the PAIRING rather than each half. A node pointed at its own bundler without the
-    // self-entry silently refuses its own uploads; the self-entry without the loopback target is
-    // a widening that buys nothing. Either alone is a misconfiguration.
+    // Assert the PAIRING rather than each half: a loopback bundler needs the route carve-out to
+    // let the node's own upload through, and a carve-out without a loopback target is a widening
+    // that buys nothing. Either alone is a misconfiguration.
+    //
+    // ⚠️ The pairing used to be loopback <-> a node SELF-ENTRY in `deploy-wallets`, and that never
+    // worked: the node signs its uploads on the nested item, never on the envelope, so p4 sees no
+    // signer and no wallet list can match. Shipping it stalled publishing on stage and live and
+    // cost 8 slots. The self-entry is now redundant and should be ABSENT — it granted the node
+    // identity slot-consuming and spawn rights for nothing.
     const bundlerTarget = (await info(host))?.['bundler-ans104']
     const selfBundling = typeof bundlerTarget === 'string' && /127\.0\.0\.1|localhost/.test(bundlerTarget)
-    check(selfBundling === (dwSelf.length === 1),
-      'self-bundling configured coherently (loopback bundler <-> node self-entry in deploy-wallets)',
-      `bundler=${bundlerTarget ?? '(unset)'} selfEntry=${dwSelf.length}`)
+    // Read here rather than reusing the `bundlerRoutes` computed further down: that one lives
+    // after this block, and a forward reference would be `undefined` at run time rather than a
+    // compile error.
+    const carveOuts = (await listOf(host, 'p4-non-chargable-routes'))
+      .map(r => r?.template)
+      .filter(r => typeof r === 'string' && /bundler/i.test(r))
+    check(selfBundling === (carveOuts.length > 0),
+      'self-bundling configured coherently (loopback bundler <-> ~bundler@1.0 route carve-out)',
+      `bundler=${bundlerTarget ?? '(unset)'} carveOut=${carveOuts.length}`)
+    check(dwSelf.length === 0,
+      'deploy-wallets carries NO node self-entry (it never admitted the upload and grants slots + spawn)',
+      dwSelf.length ? String(dwSelf[0]) : 'none')
   } else {
     check(p4?.['pricing-device'] === 'faff@1.0' && p4?.['ledger-device'] === 'faff@1.0',
       'final hook is p4 with faff pricing + ledger devices',
@@ -333,7 +348,13 @@ for (const env of targets) {
 
   // --- native: p4 carve-outs ---------------------------------------------
   const routes = (await listOf(host, 'p4-non-chargable-routes')).map(r => r?.template)
-  check(routes.length === 7, 'p4-non-chargable-routes has exactly 7 entries', `got ${routes.length}`)
+  // 7 base entries, plus the bundler carve-out on an environment that self-bundles. The carve-out
+  // is legitimate ONLY where the edge refuses `~bundler@1.0` outright — see the paired assertion
+  // further down, which is the one that actually protects the wallet.
+  const bundlerRoutes = routes.filter(r => typeof r === 'string' && /bundler/i.test(r))
+  check(routes.length === 7 + bundlerRoutes.length,
+    `p4-non-chargable-routes has exactly ${7 + bundlerRoutes.length} entries (7 base + ${bundlerRoutes.length} bundler)`,
+    `got ${routes.length}`)
   // `.every()` is true for an empty list, so each assertion below is paired with a
   // length guard — otherwise a container that failed to parse reads as a clean pass.
   check(routes.length > 0 && routes.every(t => typeof t === 'string' && t.startsWith('^/')),
@@ -622,8 +643,14 @@ for (const env of targets) {
       // Treat any 2xx as acceptance regardless of body, so a future response-shape change
       // cannot quietly turn this into a pass.
       const accepted = res.status >= 200 && res.status < 300
+      // ⚠️ WHAT THIS ACTUALLY ASSERTS depends on the node. Through a real edge that refuses
+      // `~bundler@1.0` the request never reaches p4, so a pass here is evidence about the EDGE and
+      // says nothing about the pricing device. On a node with no edge it is evidence about p4. It
+      // is a genuine check either way — the property is "a stranger cannot make us spend AR" — but
+      // do not read a pass as proof that p4 gates the bundler. It usually does not; on stage and
+      // live the carve-out means it deliberately does not.
       check(!accepted,
-        'bundler REFUSES an item from a non-allow-listed signer (acceptance would spend our AR)',
+        'a stranger CANNOT get an item bundled (edge or p4, whichever is the control here)',
         `HTTP ${res.status}`)
 
       // `verify_message` rejects `unsigned_item` before anything is queued or metered. This is
@@ -641,12 +668,31 @@ for (const env of targets) {
         `HTTP ${unsignedBundle.status}`)
     }
 
-    // A p4 carve-out for the bundler would exempt it from charging entirely, i.e. remove the
-    // only gate in front of a spending endpoint. Nothing should ever put it here, so assert
-    // the absence rather than trusting review to catch it.
-    check(!routes.some(r => typeof r === 'string' && /bundler/i.test(r)),
-      'no p4-non-chargable carve-out for ~bundler@1.0 (a carve-out would ungate spending)',
-      routes.filter(r => typeof r === 'string' && /bundler/i.test(r)).join(' ') || 'none')
+    // THE bundler invariant, and it is CONDITIONAL — an earlier version of this check asserted
+    // the carve-out was never present, full stop, which is right for an open edge and wrong for a
+    // closed one.
+    //
+    // `~bundler@1.0` accepts items this node pays an L1 reward to bundle, so exactly one control
+    // must stand in front of it. p4 cannot be that control on a node that self-bundles: the node
+    // signs its uploads on the nested item, never on the envelope (`hb_http:post` does not commit
+    // what it sends), so the gate sees an unsigned request and would have to admit the route for
+    // self-bundling to work at all. p4 is also the wrong layer for the actual risk, which is
+    // VOLUME rather than identity — a large body is parsed and its nested item deserialized
+    // before any pricing device runs.
+    //
+    // So the rule is a PAIR, and this asserts the pair rather than either half:
+    //   carve-out present  ->  the edge MUST refuse ~bundler@1.0   (stage, live)
+    //   carve-out absent   ->  p4 is the control, as on the open dev edge
+    // Getting this wrong in the permissive direction puts a funded wallet behind an open
+    // endpoint, which is why it is asserted behaviourally against the real edge, not from config.
+    if (bundlerRoutes.length > 0) {
+      const edge = await get(host, '/~bundler@1.0/tx')
+      check(edge.status === 403 || edge.status === 404,
+        'bundler carve-out is paired with an edge that REFUSES ~bundler@1.0',
+        `carve-out ${bundlerRoutes.join(' ')} + edge HTTP ${edge.status}`)
+    } else {
+      check(true, 'no p4 carve-out for ~bundler@1.0 — p4 is the control on this node', 'none')
+    }
   }
 }