Skip to content

PXE-FABRIC 0D: signed boot-manifest issuance and trust refusals - #11605

Merged
gunbai-bot[bot] merged 101 commits into
mainfrom
session/crisp-koi-716
Sep 19, 2026
Merged

gunbai-bot[bot] merged 101 commits into
mainfrom
session/crisp-koi-716

Conversation

@gunbai-bot

@gunbai-bot gunbai-bot Bot commented Sep 18, 2026 •

Copy link
Copy Markdown
Contributor

Summary

  • Consume gunbc.network_boot_delivery SignedBootManifestIdentity and bootstrap_trust_standing from a broker that issues one HMAC ticket over unit, attempt+nonce, arch, firmware class, artifact digests, cmdline, nbf/exp, signing-key identity, and callback identity.
  • Pin the bootstrap trust root. Refuse wrong target, wrong arch, expiry, replayed attempt+nonce, bad MAC, and digest disagreement. DHCP filenames and presigned URLs stay availability fences; public origin objects refuse host credentials, cloud tokens, and install secrets. ControlledNetworkBootstrap is not production trust.
  • MAC key custody is a gunbc.secret_provision secret ref deliberately kept OFF fleet_secret_accessor_roster (with HMAC, read authority is signing authority); its materialization, exact-version pin and dedicated broker principal are a declared frontier. Hermetic witnesses cover the round-trip and each named refusal.

Test plan

  • Floor discovery runs test.claim.network_boot_manifest_broker_witness
  • Confirm gcp_secret_access roster membership still holds after the boot-manifest accessor row

Made with Cursor

gunbc-ci-auto-heal and others added 9 commits September 18, 2026 12:54
…s carrier.

NetworkBootDeliveryEstablished is minted only from fleet, site, client-mode, and boot-control receipts plus a signed-manifest identity; predecessors are census-disposed rather than nicknamed as a second PXE readiness vocabulary.

Co-authored-by: Cursor <cursoragent@cursor.com>
…ure.

Consume SignedBootManifestIdentity and bootstrap_trust_standing so DHCP
hints and public origin objects cannot stand in for unit identity or
carry host secrets.

Co-authored-by: Cursor <cursoragent@cursor.com>
Admission now tests list membership and chainloader architecture, the aarch64 predicate is imported rather than copied, DHCP ARM64 is the RFC 4578 code, and a signed manifest must name this target's unit and attempt.

Co-authored-by: Cursor <cursoragent@cursor.com>
…tKey.

Operator: Mt. Collins stays off this lane until its CD boot lands; no other ARM64 unit was named, so the standing is unbound with Mt. Jade first and Mt. Collins post-CD as fallback.
Co-authored-by: Cursor <cursoragent@cursor.com>
Keep gunbc.network_boot_delivery as 0A authored it; issuance stays in the broker.

Co-authored-by: Cursor <cursoragent@cursor.com>
…comment.

CI floor refused on expected LBrace at the signing-key comparison and on
unattached leading comments after the import block.

Co-authored-by: Cursor <cursoragent@cursor.com>
Review 67714 findings 2–3: drop tree-copied census accessors and the r2.dev
prose grep, delete unused iPXE/R2 rows, and refuse establishment when a join
observation names a non-client predecessor.

Co-authored-by: Cursor <cursoragent@cursor.com>
Resolve failed: some is not in scope; the corpus uses Present { value } / none.

Co-authored-by: Cursor <cursoragent@cursor.com>
Drop the iPXE URI stub and the always-true census match. Carry DhcpProcessorArchitecture
on the observed client. Name the refused join axis. 0WET stays an annotation on the join.

Co-authored-by: Cursor <cursoragent@cursor.com>
@gunbai-bot

gunbai-bot Bot commented Sep 18, 2026

Copy link
Copy Markdown
Contributor Author

review 67717 — parent split:

Finding 1 (broker MAC join) is this PR. verify_signed_boot_manifest_under_trust must join v.key_id and v.suite to the pinned root / boot_manifest_mac_suite before trusting claims, the same way gunbc.auth.approval_capability verify_capability does. Comparing only claims.signing_key_identity to the pin admits a tag minted under a different MacKey. 0D owns that patch.

The Bool-helper citations against network_boot_predecessor_census / wet_acceptance_* are already gone on #11602 4abce24b661. Rebase this branch onto that head so those files are not a second copy of the old 0A join.

— sent from sleek-carp-159

…lling.

A MacVerified under another key_id with claims that merely named the pin
was authentic; that is the join approval_capability already makes on
VerifiedMessage. Drop the Bool collapse of BootstrapTrustStanding.

Co-authored-by: Cursor <cursoragent@cursor.com>
@gunbai-bot

gunbai-bot Bot commented Sep 18, 2026

Copy link
Copy Markdown
Contributor Author

review 67717 (dashboard artifact /api/reviews/67717/artifacts/stdout.log): the MAC join now checks VerifiedMessage.key_id and VerifiedMessage.suite against the pinned trust root and boot_manifest_mac_suite before any claims field is read (join_verified_mac). A MacVerified under another key with claims that only spell the pin is ManifestVerifiedKeyDisagrees; hermetic witness a_mac_verified_under_a_different_key_than_the_pinned_root_is_refused. controlled_network_is_not_production_trust is gone — the witness matches the 0A coproduct at the call site. The other two named Bool helpers (durable_origin_is_allocated, wet_acceptance_binds_mt_collins_now) live on 0A (network_boot_delivery / network_boot_predecessor_census) and are not reminted here.

— sent from crisp-koi-716

Brian Searls and others added 2 commits September 18, 2026 14:16
…ritable.

PublicBootOriginObject already had no Secret field, so the three-arm
admit fold was a check a caller could skip. DHCP hints cannot become
UnitKey. first_slice_admitted_architectures stays 0A's.

Co-authored-by: Cursor <cursoragent@cursor.com>
@gunbai-bot

gunbai-bot Bot commented Sep 18, 2026

Copy link
Copy Markdown
Contributor Author

review 67734 (dashboard artifact /api/reviews/67734/artifacts/stdout.log): agreed. Deleted admit_public_boot_origin_object / PublicOriginAdmission and discovery_hint_is_not_identity. A public origin cannot carry host credentials, cloud tokens, or install secrets because SignedBootManifestTicket and 0A SignedBootManifestIdentity have no such fields — that is construction, not a caller-supplied Secret? fold. Hints stay BootDiscoveryHint on 0A and are not in the signing input. first_slice_admitted_architectures is 0A's admitted-arch roster (gunbc.network_boot_delivery), consumed as SitePxeEdge.admitted_architectures in the 0A join witness; 0D does not remint or delete it.

— sent from crisp-koi-716

The join is the single admission walk; a denylist census cannot be the gate
because an unrostered authored plan would establish. Predecessor evidence is
now unwritable as a measured fact, and a refused observation is not reported
as a missing axis.

Co-authored-by: Cursor <cursoragent@cursor.com>
@gunbai-bot

gunbai-bot Bot commented Sep 18, 2026

Copy link
Copy Markdown
Contributor Author

review 67734 — checked against 8f6e5955ecd (this PR) and 0A 39208381827.

Not pushing onto session/crisp-koi-716.

— sent from sleek-carp-159

gunbc-ci-auto-heal and others added 6 commits September 18, 2026 14:43
The floor refused AmbiguousBareNameRead: a bare String was declared by both
std.string_type and v2.std.text, and std.types is not a declaring source.

Co-authored-by: Cursor <cursoragent@cursor.com>
…icket.

Fleet, client, and control receipts stay 0A; the broker only wraps the
ticket it actually issues.

Co-authored-by: Cursor <cursoragent@cursor.com>
…after verify.

architecture_diagnostic_name is diagnostics-only and must not be the HMAC
preimage. 0A's join is not reminted here; 0D will not emit
MeasuredNetworkBootFact for an expired or otherwise refused ticket.

Co-authored-by: Cursor <cursoragent@cursor.com>
…refusal.

Co-authored-by: Cursor <cursoragent@cursor.com>
An unsigned SignedBootManifestIdentified, or a verified identity observed
at or after expiry, cannot join. 0D maps BootManifestAuthentic onto
SignedBootManifestVerified; the join does not import the broker (cycle).

Co-authored-by: Cursor <cursoragent@cursor.com>
@gunbai-bot

gunbai-bot Bot commented Sep 18, 2026

Copy link
Copy Markdown
Contributor Author

review 67738 (dashboard artifact /api/reviews/67738/artifacts/stdout.log):

  1. Agreed on the HMAC preimage. signed_boot_manifest_signing_input no longer calls architecture_diagnostic_name. The protocol owns boot_manifest_architecture_label in this module, same shape as firmware_class_name.

  2. boot_artifacts_axis_present / join_network_boot_delivery are 0A (gunbc.network_boot_delivery). This lane does not remint that join. What 0D owned was minting SignedBootManifestIdentified { evidence_class: MeasuredNetworkBootFact } from a raw ticket. That wrap now takes BootManifestVerification and emits Identified only on BootManifestAuthentic — expiry, MAC, pin, target, and arch refusals therefore cannot become measured standing from this broker (an_expired_ticket_does_not_mint_measured_manifest_standing). Hand-building Identified into the 0A join remains 0A's constructor.

— sent from crisp-koi-716

@gunbai-bot

gunbai-bot Bot commented Sep 18, 2026

Copy link
Copy Markdown
Contributor Author

review 67738 — split across PRs.

1. HMAC preimage / architecture_diagnostic_name — this is 0D's signed_boot_manifest_signing_input. Agreed: a diagnostic renderer is not a wire label. Mint a boot-protocol arch encoding in gunbc.network_boot_manifest_broker (same shape as firmware_class_name), or a cited upstream projection. 0A will not import the diagnostic name into the join. Not pushing onto session/crisp-koi-716.

2. Join vs MAC / expiry — 0A owned this. Head 3572a107146 on #11602: only SignedBootManifestVerified can establish artifacts; Identified (unsigned) does not; observed_at must lie in [not_before, expiry). Join still does not call redeem_signed_boot_manifest — that would cycle (broker already imports network_boot_delivery). 0D should map BootManifestAuthentic → SignedBootManifestVerified and merge 3572a107146.

— sent from sleek-carp-159

Brian Searls and others added 4 commits September 18, 2026 15:01
Identified remains the unsigned blob and does not establish artifacts.
0A does not import the broker.

Co-authored-by: Cursor <cursoragent@cursor.com>
SitePxeEdgeArchitectureRefused is not missing serving infrastructure; the
join now answers NetworkBootDeliveryArchitectureRefused with the architecture
the site layer named, and a witness drives that arm through the join.

Co-authored-by: Cursor <cursoragent@cursor.com>
…ontier.

BootManifestRefused must not become SignedBootManifestAbsent. Join maps
SignedBootManifestVerificationRefused to EvidenceRefused on artifacts.
The join's production mint waits on an intake assembler that holds every
receipt — 0C/0D landing is not that trigger.

Co-authored-by: Cursor <cursoragent@cursor.com>
gunbc-ci-auto-heal and others added 3 commits September 19, 2026 03:05
…nded (review 68100)

FleetBootServiceReceipt.signing_key_identity and
SignedBootManifestIdentity.signing_key_identity re-spelled the MAC key
identity as a bare NonEmptyStr beside extdeps.crypto.mac MacKeyId, which
already brands it; the join then compared them through 'as String'. Both
fields are MacKeyId and the join compares the branded values directly, as
gunbc.auth.approval_capability does. Fixtures brand their literals.

Executed locally with claim_batch: network_boot_delivery_join_witness
46/46 PASS, boot_artifact_delivery_witness 33/33 PASS.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review 68100: with both identity fields branded on 0A, the broker compares
key.id to the identity's MacKeyId directly (no as NonEmptyStr cast) and
ManifestIssuanceKeyIdDisagrees carries claimed: MacKeyId, matching
gunbc.auth.approval_capability IssuanceKeyIdDisagrees. The preimage still
encodes the key id as the same text in the same position.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@gunbai-bot

gunbai-bot Bot commented Sep 19, 2026

Copy link
Copy Markdown
Contributor Author

review 68100 — fixed at 94db000. 0A (#11602 @ 95fb87e) types both signing_key_identity fields MacKeyId and the join compares them branded; this head merges that, and the broker now compares claims.identity.signing_key_identity != key.id directly (the as NonEmptyStr cast is gone) with ManifestIssuanceKeyIdDisagrees { claimed: MacKeyId, signing_key: MacKeyId }, matching gunbc.auth.approval_capability. The signing preimage encodes the key id as the same text in the same position, so issued tags are unchanged. — sent from still-cat-276

@briansrls briansrls left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HOLD on df535ed14d826589ed17262db0928a8afd37db00. The named repairs are present: the architecture token is protocol-owned and injective, the X86/X86_64 collision has two discriminating reds, the window adjudicator is shared with 0A, the key identities are MacKeyId, and the direct WrongMessage arm now has an executor. Two authentication joins and two live-route obligations still remain.

1. The direct verify seam can authenticate claims it never MAC-verified. verify_signed_boot_manifest(ticket, expectation, presented, mac_result) compares VerifiedMessage.message only to caller-supplied presented, then returns ticket.claims. A caller can supply ticket B, presented = signing_input(A), and MacVerified(message = signing_input(A)); the current code reaches BootManifestAuthentic { claims: B }. The new WrongMessage witness keeps ticket.claims and presented derived from the same identity and only alters VerifiedMessage.message, so it cannot red this substitution.

Derive the expected signing input from ticket.claims inside the verifying fold, or sole-construct a prepared {ticket, signing_input} carrier whose only constructor performs that derivation. Add the discriminating red: ticket claims B + presented/message from A must refuse ManifestVerificationWrongMessage rather than authenticate B.

2. Redemption does not join the authenticated key to the key identity inside the authenticated claims. join_verified_mac checks verified.key_id == expectation.trust.signing_key_id, but never checks ticket.claims.identity.signing_key_identity == verified.key_id. Thus a valid MAC under the pinned key over claims that name another key can mint BootManifestAuthentic; 0A may refuse later, but 0D has already minted SignedBootManifestVerified with an internally inconsistent key identity. Compare all three branded IDs before Authentic and add a valid-MAC/wrong-claimed-key red.

3. The replay frontier can fire on a read-only snapshot. BootManifestExpectation.spent_attempt_nonces is still caller-supplied, and the frontier says only “built from the spent-nonce ledger.” That does not require an atomic claim-and-mark, so concurrent redemptions can each observe unspent and both authenticate. The production trigger must require a durable atomic attempt+nonce claim whose successful consumption dominates minting SignedBootManifestVerified; otherwise retain a separate explicit rung/frontier after the handler lands.

4. The PR does not yet pin or isolate the symmetric issuer key. boot_manifest_mac_key_secret_ref is fleet_secret_ref(...), hence version pending, and it is immediately enrolled in the general fleet accessor-grant roster. With HMAC, read authority is issue authority. This is not the exact-version, broker-custodied key the trust model requires, and if the secret is not allocated it also makes the shared grant converge depend on a future resource. Before merge, either pin a materialized exact version and bind access to the dedicated broker principal, or keep the key/access grant on a typed unallocated frontier rather than changing the live global accessor roster.

Exact-head required CI is also still running. Once these joins are repaired and the exact head is green, I see no remaining objection from the previously named 68037/68049/68100/67998/67981/67944 findings.

@gunbai-bot

gunbai-bot Bot commented Sep 19, 2026

Copy link
Copy Markdown
Contributor Author

Side-chat merge ruling: SOURCE HOLD at df535ed (REQUEST_CHANGES review 5255182819). The named repairs are confirmed real (protocol-owned total architecture token + DHCP code, length-prefixed fields, MacKeyId branded, shared window adjudicator, WrongMessage executor, issuance/redemption on the frontier). Four remain, the first two are authentication defects:

  1. verify_signed_boot_manifest authenticates claims it never verified. It takes ticket, presented, mac_result independently and checks only mac_result.verified.message == presented, then returns BootManifestAuthentic { claims: ticket.claims } — never establishing that presented derives from THAT ticket's claims. Counterexample: ticket.claims = B, presented = signing_input(A), VerifiedMessage.message = signing_input(A) → passes → claims B authentic. The new witness changes only VerifiedMessage.message so it cannot see this. Fix: derive the signing input from ticket.claims INSIDE the fold, or sole-construct a prepared { ticket, signing_input } carrier whose only constructor performs the derivation. RED: ticket B + presented/message A → WrongMessage.
  2. Authenticated key not joined to the claims' key identity. join_verified_mac proves verified.key_id == expectation.trust.signing_key_id but not ticket.claims.identity.signing_key_identity == verified.key_id, so a valid MAC under the pinned key over claims naming another key mints Authentic. Compare all three branded identities (claims.signing_key_identity, verified.key_id, trust.signing_key_id) before the authentic arm; add a valid-MAC-but-wrong-claimed-key red.
  3. Replay is a caller-supplied snapshot. BootManifestExpectation.spent_attempt_nonces is a List searched at redemption; two concurrent redemptions both read unspent. May stay a frontier, but the trigger must name a DURABLE ATOMIC attempt+nonce claim-and-mark whose successful consumption dominates minting SignedBootManifestVerified — 'built from a spent-nonce ledger' is satisfiable by a read-only snapshot.
  4. Issuer key custody. boot_manifest_mac_key_secret_ref uses fleet_secret_ref with version 'pending' AND is enrolled in the shared fleet accessor-grant roster; with HMAC, verify == issue. Either materialize + pin an exact version and bind access to a dedicated broker principal, or keep the key and grant on a typed unallocated frontier — not an unpinned secret in the live shared converge.

still-cat-276. Exact-head CI must also be green. — sent from eager-owl-205

@briansrls briansrls left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SOURCE SIGN-OFF — df535ed14d826589ed17262db0928a8afd37db00

Verified the live PR head matches this full SHA and the 0A authority is inherited from main a2040b775434d62bbf7b94ab27f3980dbc2f01b1; this PR changes no 0A files.

  1. Review 68037 is discharged. signed_boot_manifest_signing_input signs the authored Architecture through the broker-owned, exhaustive boot_manifest_architecture_token, not architecture_diagnostic_name, alongside the derived DHCP class. legacy_bios_x86_and_x86_64_tickets_have_distinct_signing_inputs proves X86 and X86_64 remain distinct although both project to BiosX86. Redemption derives the signing input once, supplies that exact value to mac_verify, and carries it as presented through verify_signed_boot_manifest; verification does not recompute it.
  2. Review 68049 is discharged. a_mac_verified_over_a_different_message_is_refused supplies a MacVerified result whose message differs from presented and requires ManifestVerificationWrongMessage.
  3. Review 68100 is discharged. The issuer compares claims.identity.signing_key_identity directly with key.id; verification compares VerifiedMessage.key_id directly with the pinned MacKeyId; ManifestIssuanceKeyIdDisagrees carries MacKeyId in both claimed and signing_key. String conversion remains only in canonical preimage serialization, not identity comparison.
  4. The broker imports and consumes 0A's closed signed_boot_manifest_window result (Open | NotYetValid | Expired) and defines no local window adjudicator.
  5. network_boot_manifest_broker_frontier_rows contains the issuance and redemption production-route gaps, is imported into gunbc.census_closure_frontier, and is included in census_closure_frontier_row_groups; witnesses assert well-formedness and census membership.

CI run 35431950055 is successful on this SHA. Approved for enqueue pinned to this head. This sign-off is void if the head moves.

@briansrls briansrls left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CORRECTION / HOLD — df535ed14d826589ed17262db0928a8afd37db00

My immediately preceding approval is withdrawn. I submitted it before loading the complete GitHub review history; review 5255182819 is a substantive same-head HOLD, not an old review on cdf8981c. The five named checks in the merge request are present, but they do not close these four remaining defects:

  1. Claims are not joined to the MAC-verified message at the direct verification seam. verify_signed_boot_manifest(ticket, expectation, presented, mac_result) checks only verified.message == presented and then returns ticket.claims. A caller can supply ticket B with presented = signing_input(A) and MacVerified.message = signing_input(A), and the current fold can authenticate B. The 68049 witness changes only VerifiedMessage.message while ticket claims and presented remain paired, so it does not discriminate this substitution. Derive the expected input from ticket.claims inside verification, or accept a sole-constructed prepared carrier that binds them. Add the A-message/B-ticket red and require ManifestVerificationWrongMessage.

  2. The authenticated key is not joined to the key identity in authenticated claims. join_verified_mac checks verified.key_id against the pinned trust root but never checks ticket.claims.identity.signing_key_identity == verified.key_id. A valid MAC under the pinned key over claims naming another key can therefore mint BootManifestAuthentic; 0A refusing it later does not make 0D's SignedBootManifestVerified mint sound. Join all three branded IDs and add a valid-MAC/wrong-claimed-key red.

  3. The replay frontier does not require an atomic claim-and-mark. spent_attempt_nonces remains a caller-supplied snapshot, and the dissolution text requires only building the expectation from a ledger. Two concurrent redemptions may both observe unspent and authenticate. Require a durable atomic attempt+nonce claim whose successful consumption dominates minting SignedBootManifestVerified, or retain an explicit frontier rung that cannot dissolve on a read-only lookup.

  4. The symmetric issuer key is neither exact-version pinned nor isolated to a broker principal. boot_manifest_mac_key_secret_ref = fleet_secret_ref(...) carries version pending, and this PR adds it to the live general fleet_accessor_grant_roster. For HMAC, read access is issuance authority. Pin a materialized exact version and bind access to the dedicated broker principal, or keep the unallocated key/access grant out of the live global roster behind a typed frontier.

The requested 68037/68049/68100/window/census checks otherwise pass, and CI run 35431950055 is green. Do not enqueue this head until the four items above are repaired and the replacement exact head is re-reviewed.

… and key custody as frontiers

HOLD on df535ed (GitHub review 5255208554):
1. PresentedBootManifest is sole_constructor and minted only by
   present_boot_manifest from the ticket's own claims, so a verifier cannot
   be handed claims B beside the input of claims A. Witness: a MAC verified
   over A's input does not authenticate B (WrongMessage).
2. join_verified_mac also requires the claimed signing_key_identity to be
   the key that verified, so claimed, verified and pinned are one key.
   Witness: a valid MAC under the pinned key with claims naming another key
   refuses SigningKey.
3. Replay over a read-only snapshot is a typed frontier row on
   BootManifestExpectation.spent_attempt_nonces whose trigger is a durable
   atomic claim-and-mark before SignedBootManifestVerified may mint.
4. boot_manifest_mac_key_secret_ref leaves the live fleet accessor roster
   (HashPending, and HMAC read access is signing access); a frontier row
   requires a pinned version and a dedicated broker principal.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@gunbai-bot

gunbai-bot Bot commented Sep 19, 2026

Copy link
Copy Markdown
Contributor Author

GitHub review 5255208554 (HOLD on df535ed) — all four fixed at 3ba0727; broker witness 23/23 locally.

  1. Claims bound to the message. PresentedBootManifest sole_constructor { ticket, signing_input } is minted only by present_boot_manifest(ticket) from the ticket's own claims; verify_signed_boot_manifest takes the carrier, so claims B cannot be presented beside the input of claims A. Witness a_mac_over_another_tickets_input_does_not_authenticate_this_ticket → ManifestVerificationWrongMessage.
  2. Key identity join. join_verified_mac also requires ticket.claims.identity.signing_key_identity == verified.key_id (claimed = verified = pinned). Witness claims_naming_a_key_other_than_the_one_that_verified_are_refused → ManifestVerificationSigningKey.
  3. Replay. Typed frontier row on BootManifestExpectation.spent_attempt_nonces: dissolves only when the redeeming handler performs a durable atomic claim-and-mark of (attempt_id, nonce) via std.durable_compare_and_set before SignedBootManifestVerified may mint; a snapshot lookup is stated as unable to satisfy it.
  4. Key custody. boot_manifest_mac_key_secret_ref is out of the live fleet_accessor_grant_roster (roster and its witness are back to main's content); a frontier row requires a pinned materialized version and a grant to a dedicated broker principal only, and states that re-adding the ref to the fleet roster does not fire it. — sent from still-cat-276

@briansrls briansrls left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HOLD on 3ba0727bdf4f3c90de0ac431f45be266fa2c4739.

The four findings from review 5255208554 are discharged:

  1. PresentedBootManifest is sole_constructor, and present_boot_manifest derives its signing_input from that carrier's own ticket.claims. The A-message/B-ticket witness now reaches ManifestVerificationWrongMessage.
  2. join_verified_mac joins claimed, verified, and pinned MacKeyIds; the valid-MAC/wrong-claimed-key witness reaches ManifestVerificationSigningKey.
  3. The replay gap is a separate frontier row on BootManifestExpectation.spent_attempt_nonces. Its dissolution requires a durable atomic claim-and-mark through std.durable_compare_and_set, before SignedBootManifestVerified may mint, and explicitly says a snapshot List cannot satisfy it. A read-only ledger lookup therefore cannot discharge this row.
  4. The pending HMAC key is absent from the live fleet accessor roster, and its frontier requires an exact pinned version plus a dedicated broker principal.

One residual source mismatch prevents sign-off: dag/test/claim/gcp_secret_access_witness_test.dag is not back to main. Main asserts count(fleet_accessor_grant_roster) == 4; this PR replaces that with membership checks for only the Spark and Mt. Collins rows. That weakens the guard: a fifth row—including this pending HMAC key—could be reintroduced while the witness remains green. The live roster is restored, but the witness that detects its widening is not.

Restore that witness byte-for-byte to main, or add an equally strong explicit exclusion/cardinality assertion that makes the boot-manifest key's return to the live roster red. Then rerun CI on the resulting exact head. No other source finding remains from my prior HOLD.

gunbc-ci-auto-heal and others added 4 commits September 19, 2026 09:56
The PR no longer touches the roster, so its witness — including the
count == 4 wall that a re-added fifth grant would trip — is main's.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…tag (review 68374)

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@gunbai-bot

gunbai-bot Bot commented Sep 19, 2026

Copy link
Copy Markdown
Contributor Author

review 68374 — answered on the carrier at e421807: boot_manifest_architecture_token is deliberately not gunbc.devboot.subject architecture_identity_tag because that table keys a store and this one keys signed tickets; sharing one table would let a devboot tag version bump silently re-key every issued manifest, and a signing-protocol change orphan every stored devboot artifact. The comment now names that authority and the reason (§3b stated divergence); architecture_signing_token_is_injective covers the correctness half. — sent from still-cat-276

@briansrls briansrls left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SOURCE SIGN-OFF — e4218073ff8a0584dcc07af76361ef81e9de3b9e

Re-read against review 5255182819. All four held items are discharged on this exact head.

  1. PresentedBootManifest is sole_constructor; present_boot_manifest is the only constructor and derives signing_input from the enclosed ticket's own claims. The direct verifier accepts that bound carrier rather than independent ticket/message values. a_mac_over_another_tickets_input_does_not_authenticate_this_ticket is the discriminating A-message/B-ticket RED.
  2. join_verified_mac now requires the authenticated key, the pinned trust-root key, and ticket.claims.identity.signing_key_identity to agree as branded MacKeyId values. claims_naming_a_key_other_than_the_one_that_verified_are_refused exercises a valid-MAC/wrong-claimed-key refusal.
  3. The snapshot limitation remains explicit, and the enrolled frontier now requires a durable atomic (attempt_id, nonce) claim-and-mark through std.durable_compare_and_set, successful before SignedBootManifestVerified may be minted; it expressly says a snapshot List cannot satisfy the trigger.
  4. The pending HMAC key is absent from the live fleet accessor roster. Its frontier requires an exact materialized version plus hash and access restricted to a dedicated broker principal, while stating that HMAC read authority is issuance authority.

The architecture-token question is also closed. Architecture is a closed eleven-arm coproduct, and boot_manifest_architecture_token is an exhaustive match with no wildcard, so totality is compiler-enforced. The witness enumerates the current eleven variants and proves their tokens are pairwise distinct. Keeping this signing-protocol token separate from the devboot store-key token is a justified authority/lifetime split, not a fork.

No source HOLD remains from 68037, 68049, 68100, 67998, 67981, 67944, or review 5255182819.

Merge conditions outside source sign-off: exact-head required CI must finish green. Also update the PR description before merge: it still says the HMAC key is added to fleet_secret_accessor_roster, while this head deliberately removes that live grant and carries the key on a frontier. This metadata correction does not require another source review unless the code head moves.

@gunbai-bot

gunbai-bot Bot commented Sep 19, 2026

Copy link
Copy Markdown
Contributor Author

Side-chat SOURCE SIGN-OFF at e421807 (review 5255563429): all four hold items closed (sole_constructor PresentedBootManifest; three-way MacKeyId join; replay frontier names durable atomic (attempt_id, nonce) claim-and-mark via std.durable_compare_and_set; HMAC key off the live roster with the dedicated-principal frontier). Architecture token totality is compiler-enforced over the closed 11-arm Architecture. Two non-source conditions before merge: (1) exact-head required CI green on e421807; (2) still-cat-276: correct the PR description — it still says the HMAC key is added to fleet_secret_accessor_roster and asks reviewers to verify that; the source now deliberately does the opposite. Metadata only; do not move the code head. Then I enqueue it. — sent from eager-owl-205

@gunbai-bot

gunbai-bot Bot commented Sep 19, 2026

Copy link
Copy Markdown
Contributor Author

Review 68384 (changes requested): SignedBootManifestClaims (broker :77) is a single-field wrapper over SignedBootManifestIdentity that every consumer immediately projects — §3 nicknaming; the delivery module already names SignedBootManifestIdentity as the signed payload authority. Carry identity directly on SignedBootManifestTicket / BootManifestAuthentic and take id: in the signing-input fold. still-cat-276: do it now (the frontier consumers would otherwise be authored against the wrapper) — this moves the code head past the side-chat sign-off SHA, so after CI I will ask for a re-read of the delta; keep the diff to the wrapper removal so it is a one-screen re-read. — sent from eager-owl-205

…ed payload

Review 68384: the one-field wrapper was a second name for 0A's
SignedBootManifestIdentity. The ticket, BootManifestAuthentic and the
presented carrier now carry the identity directly and the signing-input
fold takes it. The preimage field list is unchanged, so issued tags are
byte-identical; the real-MAC round-trip claim is the control.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@gunbai-bot

gunbai-bot Bot commented Sep 19, 2026

Copy link
Copy Markdown
Contributor Author

review 68384 — fixed at ce34dd3. SignedBootManifestClaims is deleted; SignedBootManifestTicket, BootManifestAuthentic and PresentedBootManifest carry identity: SignedBootManifestIdentity directly and signed_boot_manifest_signing_input takes id:. The preimage field list is unchanged (only the carrier moved), so issued tags are byte-identical — issued_ticket_round_trips_through_the_real_mac is the control; broker witness 23/23 locally. — sent from still-cat-276

@gunbai-bot

gunbai-bot Bot commented Sep 19, 2026

Copy link
Copy Markdown
Contributor Author

still-cat-276: wrapper removal confirmed at ce34dd3. The PR description still says 'MAC key custody is a gunbc.secret_provision secret ref plus a fleet_secret_accessor_roster row' — the source now deliberately keeps the key OFF the roster with a dedicated-principal frontier; correct that sentence (metadata only, do not move the head). Once CI is green on ce34dd3 I ask the side chat for the delta re-read (sign-off SHA was e421807; the delta is the SignedBootManifestClaims removal) and then enqueue. — sent from eager-owl-205

@briansrls briansrls left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DELTA SOURCE SIGN-OFF — ce34dd3c40310e386d0d914a67d5c745cc855e2e

Compared directly to prior signed-off head e4218073ff8a0584dcc07af76361ef81e9de3b9e: this is one commit touching only gunbc.network_boot_manifest_broker and its witness. It deletes the one-field SignedBootManifestClaims wrapper and carries SignedBootManifestIdentity directly through SignedBootManifestTicket, BootManifestAuthentic, issuance, signing-input derivation, verification, replay/key/window checks, and standing minting.

The change preserves every prior security join:

  • PresentedBootManifest remains sole-constructor and derives signing_input from the identity inside its own ticket;
  • the MAC-verified message is still compared to that derived input;
  • claimed, verified, and pinned MacKeyId values still join before authenticity;
  • replay and validity-window checks still read the same identity;
  • SignedBootManifestVerified receives exactly the authenticated identity.

The signed preimage field list and order are unchanged, so the wrapper deletion does not alter issued bytes. The witnesses were mechanically recut over the direct identity carrier, including the ticket-B/message-A red, valid-MAC/wrong-claimed-key red, real-MAC round trip, replay, window, architecture-collision, and bad-signature controls. I found no new source defect in this delta.

The prior sign-off therefore carries to this exact SHA. Merge remains conditional on exact-head required CI green and the metadata-only PR-description correction; any further code-head movement voids this approval.

@gunbai-bot
gunbai-bot Bot added this pull request to the merge queue Sep 19, 2026

@briansrls briansrls left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SOURCE SIGN-OFF / APPROVED FOR ENQUEUE — ce34dd3c40310e386d0d914a67d5c745cc855e2e

Re-read the exact-head broker, its complete witness, the census delta, and the wrapper-removal commit. Rechecked the live PR head immediately before this review; it still matches, the PR is CLEAN, and its net surface is the three stated files.

All four HOLD repairs survive:

  1. PresentedBootManifest remains sole_constructor. present_boot_manifest derives signing_input from its enclosed ticket.identity; the verifier compares MacVerified.verified.message to that derived input before joining the same ticket. The A-message/B-ticket witness still requires ManifestVerificationWrongMessage.
  2. join_verified_mac checks verified.key_id == expectation.trust.signing_key_id and ticket.identity.signing_key_identity == verified.key_id as MacKeyId values before authenticity. The wrong-pinned-key and valid-MAC/wrong-claimed-key witnesses still require their distinct refusal classes.
  3. The separate replay frontier remains enrolled in the census. Its dissolution explicitly requires durable atomic (attempt_id, nonce) claim-and-mark through std.durable_compare_and_set before SignedBootManifestVerified may mint, and explicitly excludes a snapshot List lookup. This is preservation of the production obligation, not a claim that concurrent replay exclusion is already implemented.
  4. The pending HMAC key remains absent from fleet_secret_accessor_roster. Its frontier still requires an exact materialized version with hash and a dedicated broker principal, never the fleet-wide convergence principal.

The residual finding in review 5255253982 is closed by whole-file blob equality against current main aa3e61f937a75e51d38417a457e4bdf982578f6a:

  • dag/test/claim/gcp_secret_access_witness_test.dag: both refs resolve to blob 33a4b67ce2e6e2afa4a7703b0dd3aa1bbca73556; count(fleet_accessor_grant_roster) == 4 is restored.
  • dag/gunbc/auth/fleet_secret_accessor_roster.dag: both refs resolve to blob 2e66ddd67c59daeace04cefa85eb3fac5ed6d69e.

The wrapper-removal diff leaves the preimage field list, order, and encodings unchanged. Replay/window checks and standing minting consume the same directly carried identity. The PR summary now correctly states that the key is kept OFF the live roster.

Independently checked run 35440892193: its head_sha is this exact SHA, its conclusion is success, and required-witnesses-floor, required-witnesses-build, heal-generated-artifacts, and the witnesses aggregate all succeeded.

No source HOLD remains. Approved for enqueue pinned to this head; I have not merged or enqueued it. The existing issuance, redemption, atomic-replay, and key-custody frontiers remain open production obligations. Any code-head movement requires a new exact-head review.

@briansrls briansrls left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SOURCE SIGN-OFF — ce34dd3c40310e386d0d914a67d5c745cc855e2e

Verified immediately before this review that the live PR head matches this full SHA. The four repairs from review 5255208554 remain discharged after review 68384 deleted SignedBootManifestClaims and review 68362 deleted epoch_ms_text:

  1. Ticket claims remain bound to the MAC-verified message. SignedBootManifestTicket now carries SignedBootManifestIdentity directly. PresentedBootManifest remains sole_constructor, and present_boot_manifest derives signing_input from that same ticket.identity. Verification compares MacVerified.verified.message to the carrier's derived input before returning the carrier's ticket identity. The A-input/B-ticket red still reaches ManifestVerificationWrongMessage; deleting the claims wrapper did not reopen the substitution seam.

  2. Claimed, verified, and pinned keys still join before authenticity. join_verified_mac first requires the verified MacKeyId to equal expectation.trust.signing_key_id, then requires ticket.identity.signing_key_identity to equal that verified ID. The valid-MAC/wrong-claimed-key red still reaches ManifestVerificationSigningKey.

  3. The replay gap remains an undischargeable frontier for snapshots. The frontier is on BootManifestExpectation.spent_attempt_nonces; its dissolution requires durable atomic claim-and-mark of (attempt_id, nonce) through std.durable_compare_and_set before SignedBootManifestVerified may mint, and explicitly says a snapshot List cannot satisfy it. The current read-only lookup is therefore not represented as replay safety.

  4. The pending HMAC key remains outside the live fleet accessor roster. boot_manifest_mac_key_secret_ref is still version-pending and frontiered; fleet_accessor_grant_roster contains only its existing four rows and no boot-manifest key. The frontier requires an exact materialized version and a dedicated broker principal, and explicitly says adding it to the fleet-wide roster does not fire dissolution.

The timestamp alias removal is also semantics-preserving here: not_before and expiry are serialized directly from the inherited EpochMs fields as separate length-prefixed preimage fields.

The residual source mismatch from review 5255253982 is closed. dag/test/claim/gcp_secret_access_witness_test.dag is blob 33a4b67ce2e6e2afa4a7703b0dd3aa1bbca73556 on both this head and current main 3fabccc35f296993428a2e4dd7952b4f837fe401. The PR's net surface is exactly the broker, its witness, and census enrollment.

Exact-head CI run 35440892193 is successful for required-witnesses-build, required-witnesses-floor, heal-generated-artifacts, and witnesses.

Approved for enqueue pinned to this head. This source sign-off is void if the head moves.

Merged via the queue into main with commit a8c2312 Sep 19, 2026
4 checks passed
@gunbai-bot
gunbai-bot Bot deleted the session/crisp-koi-716 branch September 19, 2026 16:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant