8000 T99 — Re-certify bep's published root when a store registration changes · Issue #2746 · gominimal/minimal · GitHub
[go: up one dir, main page]

Skip to content

T99 — Re-certify bep's published root when a store registration changes #2746

Closed

Description

@norrietaylor

Task

slice size difficulty model who estimated lines
Round-four residuals closed M needs care standard an agent 420 (180 code, 240 tests)

A box activated right after min secret set adds an upstream trusts that upstream, with no restart of bep serve.

Covers:

  • BEP-013

Layers:

  • recertify:
    • crates/bep/src/main.rs: StoreAdmission re-issues the root and publishes it to the identity file when the control socket reports a store registration change, not only at the next CONNECT, so the next box activation reads a root that admits the new upstream (T99 — Re-certify bep's published root when a store registration changes #2746, arch condition C2 on test(e2e): prove Keychain secrets by reference end to end #2612); the CONNECT path stays the fallback for a rule file edited by hand, and a failed re-issue or publish keeps today's retry
    • crates/bep/src/control.rs: a control request that re-certifies at once and answers only after the re-issue and the publish, with ok or the reason they failed
    • cargo nextest run -p bep a_store_registration_change_recertifies_the_published_root_at_once
  • client:
    • crates/minimal/src/cmd/secret.rs: min secret set sends the re-certify request after it writes the rule, when a proxy answers on its control socket
    • crates/minimal/src/mint.rs: the control-socket client that the mint path already uses carries the re-certify request
    • cargo nextest run -p minimal secret_set_asks_a_running_proxy_to_recertify
  • e2e:

Waits on:

Found by arch-review on #2612 (T29, epic #1501, arch condition C2 at 11b0a4d8), filed by the epic owner's ruling on 2026-10-29.

Gap. Gatehouse §6.10 line 834 binds re-certification of the published root to a registration change. Today StoreAdmission in crates/bep/src/main.rs admits a widened store rule without a restart (T91, #2663), but bep re-issues the published root only at the next CONNECT. Between min secret set <id> --upstream <host> and that CONNECT, a box that activates reads the old root from the identity file, so it does not trust the new upstream, and it keeps that root.

What closes it. When a store registration changes, StoreAdmission re-certifies the published root at once, so the next box activation reads a root that admits the new upstream. Then scripts/session-e2e.sh bep_store_reference_end_to_end can drop the bep restart that #2612 keeps after min secret set, and the comment that names this issue.

Plan block
### T99 — Re-certify bep's published root when a store registration changes
  slice: S13
  kind: task
  covers: BEP-013
  size: M
  est: 180 code, 240 tests
  executor: agent
  difficulty: needs care
  model: standard
  diagnostics: when a running proxy answers that it did not re-issue or publish the root, `min secret set` says that the rule is saved, name the upstream, and say that a box created before the proxy publishes a root with the change does not reach that upstream, pinned by secret_set_asks_a_running_proxy_to_recertify; with no proxy running it prints nothing new, because `bep serve` issues its root from the current rules when it starts
  observability: bep serve logs one info line each time a registration change re-certifies the root, with the number of store rules and whether the publish succeeded; the existing error lines still name a failed re-issue or publish
  layers:
    - recertify:
      - crates/bep/src/main.rs: `StoreAdmission` re-issues the root and publishes it to the identity file when the control socket reports a store registration change, not only at the next CONNECT, so the next box activation reads a root that admits the new upstream (#2746, arch condition C2 on #2612); the CONNECT path stays the fallback for a rule file edited by hand, and a failed re-issue or publish keeps today's retry
      - crates/bep/src/control.rs: a control request that re-certifies at once and answers only after the re-issue and the publish, with ok or the reason they failed
      test: cargo nextest run -p bep a_store_registration_change_recertifies_the_published_root_at_once
    - client:
      - crates/minimal/src/cmd/secret.rs: `min secret set` sends the re-certify request after it writes the rule, when a proxy answers on its control socket
      - crates/minimal/src/mint.rs: the control-socket client that the mint path already uses carries the re-certify request
      test: cargo nextest run -p minimal secret_set_asks_a_running_proxy_to_recertify
    - e2e:
      - scripts/session-e2e.sh: `proof_bep_store_reference_end_to_end` drops the bep stop and daemon restart that #2612 keeps after `min secret set`, and the comment that names #2746; the box activates against the proxy that was already running
      test: ./scripts/session-e2e.sh bep_store_reference_end_to_end
  produces: none
  consumes: none
  proof: A box activated right after `min secret set` adds an upstream trusts that upstream, with no restart of bep serve.
  depends on:
    - blocked by #2294
    - blocked by #2618

Generated by Claude Code

Activity

  1. minimal-foundry commented on Oct 29, 2026

    @minimal-foundry
    Contributor

    Done. #2767 merged.

    branch agent/2746-re-certify-bep-s-published-root-when-a-store-reg · epic #1501 · PR #2767

    round outcome job
    1 pushed d6c7b924

    Updated 2026-10-31T01:00:22.561Z.

  2. changed the title [-]Re-certify bep's published root when a store registration changes[/-] [+]T99 — Re-certify bep's published root when a store registration changes[/+] on Oct 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      0