@consiliency/agent-board-schema 1.27.0 → 1.28.0

package/tests/isolation/specs/ledger_authority_revoke.spec

@@ -0,0 +1,290 @@
+# Consiliency/message-board#276 — a board AUTHORITY write reads the fleet revocation ledger
+# under a share lock on the actor's agents row, so a concurrent revoke_fleet_subject('agent')
+# serializes against the write instead of racing it.
+#
+# WHY THIS CANNOT BE A pgTAP FILE. The predicate ("a ledger-revoked grantor is refused") is
+# provable in one transaction and is proved in agent_board_ledger_authority.test.sql. The
+# property THIS file exists for is not the predicate: it is that the read is LOCKED. An
+# unlocked `exists (select 1 from fleet_revocation_events ...)` passes every pgTAP assertion in
+# that file and still leaves the TOCTOU wide open — the authority write reads "not revoked", a
+# revocation commits, and the grant lands anyway. A single rolled-back transaction cannot
+# produce that interleaving. isolationtester prints `<waiting ...>` / `<... completed>` whenever
+# a step blocks, so the lock is a byte in the golden rather than a claim in a comment.
+#
+# THE ADVERSARY IS THE SHIPPED FUNCTION, not a stand-in. `revoke_fleet_subject('agent', X)`
+# (20260901000100:1062) is the exact call the issue is about: it locks the machines X is bound
+# to, then the agents row FOR UPDATE, then the bindings, then writes the agent-subject ledger
+# row. That `agents` FOR UPDATE is what the gate's FOR SHARE conflicts with, and it is the sole
+# reason the two orders below produce different outcomes.
+#
+# BOTH ROUTES ARE DRIVEN, because the whole point of siting the check inside grant_board_role
+# was that the wide `authenticated` door and the narrow signed one could not diverge:
+#   ugrant  — grant_board_role called directly by the authenticated owner. No gateway.
+#   sgrant  — signed_grant_board_role called by the service_role gateway, with a decision
+#             naming a live, owned, verified key so a refusal can only be #276's gate and
+#             never #269's signer revalidation.
+#
+# The check session also reads agents.status: it must stay 'active' throughout. If a future
+# change made fleet revocation flip the status, these permutations would still pass — but for
+# a different reason — and that column in the golden is what makes the substitution visible.
+#
+# MUTATION-VERIFIED: dropping `for share` from _assert_actor_not_fleet_revoked (leaving the
+# ledger read unlocked) changes permutations 2 and 4 — the authority write no longer waits.
+# Clean schema -> byte-identical across 10 runs.
+
+setup
+{
+  insert into auth.users (id) values
+    ('27700000-0000-0000-0000-0000000000a1'),
+    ('27700000-0000-0000-0000-0000000000a2'),
+    ('27700000-0000-0000-0000-0000000000a3');
+
+  insert into agent_board.agents(id, agent_type, kind, handle, display_name, status, auth_user_id)
+  values
+    ('27710000-0000-4000-8000-000000000001','agent','agent','k276iso-owner','K276 ISO Owner','active','27700000-0000-0000-0000-0000000000a1'),
+    ('27710000-0000-4000-8000-000000000002','agent','agent','k276iso-grantee','K276 ISO Grantee','active','27700000-0000-0000-0000-0000000000a2'),
+    ('27710000-0000-4000-8000-000000000003','agent','agent','k276iso-revoker','K276 ISO Revoker','active','27700000-0000-0000-0000-0000000000a3');
+
+  insert into agent_board.boards(id, slug, name, created_by_agent_id, visibility, status)
+  values ('27720000-0000-4000-8000-000000000001','k276-iso-board','K276 ISO Board',
+          '27710000-0000-4000-8000-000000000001','private','active');
+
+  insert into agent_board.board_memberships(board_id, agent_id, role, membership_state, created_by_agent_id)
+  values
+    ('27720000-0000-4000-8000-000000000001','27710000-0000-4000-8000-000000000001','owner','joined','27710000-0000-4000-8000-000000000001'),
+    ('27720000-0000-4000-8000-000000000001','27710000-0000-4000-8000-000000000002','member','joined','27710000-0000-4000-8000-000000000001');
+
+  insert into agent_board.agent_signing_keys(
+    id, agent_id, key_id, key_version, public_key, public_key_format, fingerprint, status, proof_state)
+  values ('27730000-0000-4000-8000-000000000001','27710000-0000-4000-8000-000000000001',
+          'primary', 1, public.test_pubkey('k276-iso'), 'raw_ed25519_base64url',
+          public.test_key_fingerprint('k276-iso'), 'active', 'proven');
+
+  -- A real fleet binding, so revoke_fleet_subject('agent') walks its full path (machine locks,
+  -- agents lock, binding revocation, ledger write) rather than a degenerate one.
+  insert into agent_board.fleet_trust_domains(id, slug, display_name, domain_kind, owner_agent_id, lifecycle_state, approved_at)
+  values ('27740000-0000-4000-8000-000000000001','k276-iso-domain','K276 ISO Domain','tailnet',
+          '27710000-0000-4000-8000-000000000003','active', now());
+  insert into agent_board.fleet_machines(id, trust_domain_id, owner_agent_id, machine_label, machine_fingerprint, lifecycle_state, enrolled_at)
+  values ('27750000-0000-4000-8000-000000000001','27740000-0000-4000-8000-000000000001',
+          '27710000-0000-4000-8000-000000000003','k276-iso-machine','fp-k276-iso','active', now());
+  insert into agent_board.fleet_machine_agents(id, machine_id, agent_id, agent_role, lifecycle_state)
+  values ('27760000-0000-4000-8000-000000000001','27750000-0000-4000-8000-000000000001',
+          '27710000-0000-4000-8000-000000000001','phase_worker','active');
+
+  -- An OUTSTANDING admin link, modelled as a pre-existing row because that is what it is: a
+  -- link minted before its creator was revoked, which the mint gate structurally cannot reach.
+  -- Seeded rather than minted through create_invite_link for two reasons, both mechanical: the
+  -- generated code is random (a golden must not contain one), and board_invite_tokens carries
+  -- a CREATOR-ONLY read policy (board_invite_tokens_creator_read), so a redeem session running
+  -- as `authenticated` cannot look the code up -- it holds the code out of band, as a real
+  -- redeemer does. An earlier revision of this spec did look it up and every redemption failed
+  -- 'invite is not usable' on a null code, which the uniform error made indistinguishable from
+  -- the gate firing. The code is a literal here for exactly that reason.
+  insert into agent_board.board_invite_tokens(
+    code, board_id, preset_role, preset_membership_state, max_uses, expires_at, created_by_agent_id)
+  values ('k276isolink', '27720000-0000-4000-8000-000000000001', 'admin', 'joined', 5,
+          now() + interval '2 days', '27710000-0000-4000-8000-000000000001');
+}
+
+teardown
+{
+  delete from agent_board.signature_evidence
+   where agent_id in (select id from agent_board.agents where handle like 'k276iso-%');
+  delete from agent_board.board_invite_redemptions
+   where invite_id in (select id from agent_board.board_invite_tokens
+                        where board_id = '27720000-0000-4000-8000-000000000001');
+  delete from agent_board.board_invite_tokens
+   where board_id = '27720000-0000-4000-8000-000000000001';
+  delete from agent_board.board_membership_events
+   where board_id = '27720000-0000-4000-8000-000000000001';
+  delete from agent_board.fleet_revocation_events
+   where agent_id in (select id from agent_board.agents where handle like 'k276iso-%')
+      or subject_id in (select id from agent_board.agents where handle like 'k276iso-%')
+      or revoked_by_agent_id in (select id from agent_board.agents where handle like 'k276iso-%');
+  delete from agent_board.fleet_machine_agents where id='27760000-0000-4000-8000-000000000001';
+  delete from agent_board.fleet_machines where id='27750000-0000-4000-8000-000000000001';
+  delete from agent_board.fleet_trust_domains where id='27740000-0000-4000-8000-000000000001';
+  delete from agent_board.agent_signing_keys
+   where agent_id in (select id from agent_board.agents where handle like 'k276iso-%');
+  delete from agent_board.board_authority_ceilings where board_id='27720000-0000-4000-8000-000000000001';
+  delete from agent_board.board_memberships where board_id='27720000-0000-4000-8000-000000000001';
+  delete from agent_board.boards where id='27720000-0000-4000-8000-000000000001';
+  delete from agent_board.agents where handle like 'k276iso-%';
+  delete from auth.users where id in (
+    '27700000-0000-0000-0000-0000000000a1',
+    '27700000-0000-0000-0000-0000000000a2',
+    '27700000-0000-0000-0000-0000000000a3');
+}
+
+# The WIDE door: the authenticated owner calling the chokepoint directly, no gateway involved.
+session "ugrant"
+step "ugrant_begin" {
+  BEGIN;
+  SET LOCAL ROLE authenticated;
+  SET LOCAL "request.jwt.claim.role" = 'authenticated';
+  SET LOCAL "request.jwt.claim.sub" = '27700000-0000-0000-0000-0000000000a1';
+}
+step "ugrant_grant" {
+  select g.role as granted_role
+    from agent_board.grant_board_role(
+      '27720000-0000-4000-8000-000000000001',
+      '27710000-0000-4000-8000-000000000002',
+      'admin') g;
+}
+step "ugrant_commit" { COMMIT; }
+
+# The NARROW door. Only the deterministic column is selected -- signature_evidence_id is a
+# fresh uuid and a golden must not contain a random value.
+session "sgrant"
+step "sgrant_begin" { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "sgrant_grant" {
+  select w.role as granted_role
+    from agent_board.signed_grant_board_role(
+      jsonb_build_object(
+        'p_board_id', '27720000-0000-4000-8000-000000000001',
+        'p_agent_id', '27710000-0000-4000-8000-000000000002',
+        'p_grantee_role', 'admin'),
+      jsonb_build_object(
+        'agent_id', '27710000-0000-4000-8000-000000000001',
+        'signing_key_id', '27730000-0000-4000-8000-000000000001',
+        'key_id', 'primary',
+        'key_version', 1,
+        'algorithm', 'Ed25519',
+        'verification_status', 'verified',
+        'payload_digest', 'sha256:k276',
+        'enforcement_mode', 'require_for_agent_writes')) w;
+}
+step "sgrant_commit" { COMMIT; }
+
+session "revoke"
+step "revoke_begin" { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "revoke_agent" {
+  select subject_kind
+    from agent_board.revoke_fleet_subject(
+      'agent',
+      '27710000-0000-4000-8000-000000000001',
+      '27710000-0000-4000-8000-000000000003',
+      'k276 iso fleet revocation');
+}
+step "revoke_commit" { COMMIT; }
+
+# The invite MINT half (#276 G3). Locked like the three chokepoints: the actor IS the principal
+# whose authority is being spent, since an admin-preset link is a deferred grant of admin.
+session "mint"
+step "mint_begin" {
+  BEGIN;
+  SET LOCAL ROLE authenticated;
+  SET LOCAL "request.jwt.claim.role" = 'authenticated';
+  SET LOCAL "request.jwt.claim.sub" = '27700000-0000-0000-0000-0000000000a1';
+}
+step "mint_link" {
+  select m.preset_role
+    from agent_board.create_invite_link(
+      '27720000-0000-4000-8000-000000000001', 'admin', 'joined', 5,
+      now() + interval '2 days') m;
+}
+step "mint_commit" { COMMIT; }
+
+# The invite REDEEM half. DELIBERATELY UNLOCKED -- every way of row-locking the creator here
+# closes a cycle (enroll_federated_identity reaches this function holding a boards lock; see the
+# migration header). This session exists to record the ACCEPTED window as bytes rather than
+# prose: with the revocation in flight and uncommitted, the redemption does NOT block and
+# succeeds on its own snapshot. Permutation 6 then shows the very next redemption refused.
+session "redeem"
+step "redeem_begin" {
+  BEGIN;
+  SET LOCAL ROLE authenticated;
+  SET LOCAL "request.jwt.claim.role" = 'authenticated';
+  SET LOCAL "request.jwt.claim.sub" = '27700000-0000-0000-0000-0000000000a2';
+}
+step "redeem_link" {
+  select r.role as redeemed_role
+    from agent_board.redeem_invite_link('k276isolink') r;
+}
+step "redeem_commit" { COMMIT; }
+
+# A SECOND redeemer of the SAME token. Exists to bound the accepted window: two redemptions of
+# one token cannot both sit between their ledger read and their commit, because the token
+# FOR UPDATE is the redeem path's first statement. Permutation 8 drives exactly that.
+session "redeem2"
+step "redeem2_begin" {
+  BEGIN;
+  SET LOCAL ROLE authenticated;
+  SET LOCAL "request.jwt.claim.role" = 'authenticated';
+  SET LOCAL "request.jwt.claim.sub" = '27700000-0000-0000-0000-0000000000a3';
+}
+step "redeem2_link" {
+  select r.role as redeemed_role
+    from agent_board.redeem_invite_link('k276isolink') r;
+}
+step "redeem2_commit" { COMMIT; }
+
+session "check"
+step "check" {
+  select
+    (select role from agent_board.board_memberships
+      where board_id = '27720000-0000-4000-8000-000000000001'
+        and agent_id = '27710000-0000-4000-8000-000000000002') as grantee_role,
+    (select status from agent_board.agents
+      where id = '27710000-0000-4000-8000-000000000001') as owner_status,
+    (select count(*) from agent_board.fleet_revocation_events
+      where subject_kind = 'agent'
+        and subject_id = '27710000-0000-4000-8000-000000000001') as agent_ledger_rows,
+    (select count(*) from agent_board.fleet_machine_agents
+      where agent_id = '27710000-0000-4000-8000-000000000001'
+        and lifecycle_state = 'active') as active_bindings,
+    (select count(*) from agent_board.board_invite_tokens
+      where board_id = '27720000-0000-4000-8000-000000000001'
+        and code <> 'k276isolink') as minted_tokens,
+    (select uses_count from agent_board.board_invite_tokens
+      where code = 'k276isolink') as outstanding_link_uses;
+}
+
+# 1. Write first (UNSIGNED). The revocation must WAIT on the share-locked agents row rather
+#    than committing underneath a grant that has already been authorized. The grant stands and
+#    the revocation lands after it -- a grant that beat the revocation, which is the same
+#    outcome as a grant one millisecond earlier.
+permutation "ugrant_begin" "ugrant_grant" "revoke_begin" "revoke_agent" "ugrant_commit" "revoke_commit" "check"
+
+# 2. THE DEFECT'S OWN INTERLEAVING, unsigned route. The revocation is in flight when the
+#    authority write runs; the write blocks on the agents row, then observes the committed
+#    revocation and fails closed. Before #276 this permutation COMPLETED the grant: the
+#    chokepoint read no ledger at all, so there was nothing to block on and nothing to see.
+permutation "revoke_begin" "revoke_agent" "ugrant_begin" "ugrant_grant" "revoke_commit" "ugrant_commit" "check"
+
+# 3. Write first, SIGNED route. Same property through the gateway wrapper, which reaches the
+#    gate only because the check lives inside the inner chokepoint.
+permutation "sgrant_begin" "sgrant_grant" "revoke_begin" "revoke_agent" "sgrant_commit" "revoke_commit" "check"
+
+# 4. The defect's interleaving through the SIGNED route. #269 already made this wrapper block
+#    on the agents row for a STATUS change; this permutation is what proves it also fails
+#    closed on a LEDGER revocation, which leaves agents.status untouched.
+permutation "revoke_begin" "revoke_agent" "sgrant_begin" "sgrant_grant" "revoke_commit" "sgrant_commit" "check"
+
+# 5. The MINT half, revoke-in-flight. The mint blocks on the creator's agents row, then observes
+#    the committed revocation and fails closed -- and leaves no token, so no code escapes. This
+#    is the permutation the FOR SHARE in _assert_actor_not_fleet_revoked exists for on this path.
+permutation "revoke_begin" "revoke_agent" "mint_begin" "mint_link" "revoke_commit" "mint_commit" "check"
+
+# 6. THE ACCEPTED WINDOW, recorded rather than described. The outstanding link exists, the
+#    revocation is IN FLIGHT and uncommitted, and the redemption does NOT block -- it reads its
+#    own snapshot and succeeds. That is the TOCTOU this migration deliberately accepts on the
+#    redeem path, because every row lock that would close it closes a deadlock cycle instead
+#    (see the header). The check row shows the use consumed; the pgTAP file shows the NEXT
+#    redemption, after the revocation commits, refused.
+permutation "revoke_begin" "revoke_agent" "redeem_begin" "redeem_link" "redeem_commit" "revoke_commit" "check"
+
+# 7. ...and the same interleaving with the revocation COMMITTED first: now the redemption is
+#    refused. The pair is what makes permutation 6 a bounded window rather than an open door.
+permutation "revoke_begin" "revoke_agent" "revoke_commit" "redeem_begin" "redeem_link" "redeem_commit" "check"
+
+# 8. THE RESIDUAL BOUND, driven rather than argued. Two redeemers of the SAME token with the
+#    revocation in flight: the first reads the ledger before the revocation commits and slips
+#    through; the second BLOCKS on the token row -- board_invite_tokens FOR UPDATE is the redeem
+#    path's first statement -- and by the time it proceeds the revocation has committed, so its
+#    own ledger read refuses it. That is why the disclosure says "at most one redemption per
+#    outstanding token" and not "one redemption": tokens serialise redemptions of themselves,
+#    but a creator holding K links has K independent windows. outstanding_link_uses = 1 in the
+#    check row is the byte that says exactly one slipped.
+permutation "revoke_begin" "revoke_agent" "redeem_begin" "redeem_link" "redeem2_begin" "redeem2_link" "revoke_commit" "redeem_commit" "redeem2_commit" "check"

package/tests/isolation/specs/signer_lifecycle_revoke.spec

@@ -39,6 +39,16 @@
 #                           its MODE observable. The table's UPDATE privilege is the
 #                           owner's alone (service_role has SELECT), so this models
 #                           owner-level incident DML and any future key-only writer.
+#
+# GOLDEN CHANGE IN #276, recorded so it is not read as a #269 regression. Permutation 2's
+# refusal line moved from `signer_not_active` to `fleet_revoked`. `revoke_agent_subtree`'s
+# primitive produces BOTH conditions at once — it flips agents.status AND writes an
+# agent-subject fleet_revocation_events row — and #276's gate, which lives inside
+# grant_board_role, now runs before _assert_signed_authority_signer_live and wins the race to
+# raise. The blocking behaviour this permutation exists for is unchanged (`<waiting ...>` /
+# `<... completed>` are byte-identical), and `signer_not_active` is still exercised
+# EXCLUSIVELY by permutations 3 and 4, whose `suspend` session touches only agents.status and
+# writes no ledger row. Nothing here stopped being pinned.
 
 setup
 {