You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The registrar red-team and endurance scenarios both create an isolated live OpenBao/Step CA deployment, but their scripts retain parallel copies of shared deployment and supervisor setup even though scripts/impl/lib/registrar-docker.sh exists for their common launcher support. The endurance work also required a narrow production change: LeafWithChain publication now adds configured trust anchors that the ACME response lacks, allowing a caller with an unchanged root-anchor pin to reach a renewed registrar endpoint leaf. That behavior was merged without the separate pull-request disclosure required for a production fix exposed by an E2E scenario.
Scope
Extract the common registrar live-deployment setup used by scripts/impl/run-registrar-redteam.sh and scripts/impl/run-registrar-endurance.sh into narrowly scoped shared support under scripts/impl/lib/registrar-docker.sh or an adjacent shared registrar launcher library. Update both scenarios to use that one implementation while leaving their distinct assertions and workloads local to each script. The run's instance-name derivation is part of that common setup: derive it in the shared helper against the budget the binary validates (MAX_INSTANCE_NAME_LEN, src/commands/compose_project.rs) rather than an endurance-local literal, keeping the name each arm derives today unchanged for every run token either launcher passes. Record the already-merged LeafWithChain configured-anchor publication where it survives review, which is in the tree rather than in a pull-request description. Document append_configured_anchors (src/acme/flow.rs:788) beside the function itself or in the registrar reference under docs/reference/: the [trust].ca_bundle_path condition it is gated on, why an unchanged root-anchor pin needs it across leaf renewal, and that src/registrar_certs.rs:122 (SURFACE_LEAF_PUBLICATION) is its only LeafWithChain consumer today while any future consumer inherits the behavior, since the change sits in the shared publication arm rather than in registrar-specific code. A pull-request description is not the place for it: that disclosure was owed when #783's pull request merged, and restating it in a later, unrelated pull request buries it where no later reader looks.
Acceptance criteria
The two registrar scenario scripts use one shared implementation for their common isolated-deployment and daemon-supervisor setup; scenario-specific red-team and endurance assertions remain in their respective scripts.
The shared helper preserves per-run instance names, containers, ports, temporary paths, artifact locations, and cleanup ownership for both scenarios.
The red-team checked-out-project/binary/artifact launcher contract and the endurance extended-suite case contract remain intact.
The already-merged LeafWithChain anchor publication is documented in the tree, where a later reader will find it — beside append_configured_anchors in src/acme/flow.rs or in the registrar reference under docs/reference/ — covering the [trust].ca_bundle_path gate, the unchanged-root-anchor renewal rationale, and that src/registrar_certs.rs:122 is its sole LeafWithChain consumer today with any future consumer inheriting the behavior. A pull-request description does not satisfy this criterion.
The refactor does not change certificate lifetimes, renewal cadence, endpoint pin semantics, or add production tracing/test seams.
Constraints
Keep shared support limited to behavior both scenarios genuinely use; do not turn the library into a replacement for either scenario's assertions. Do not copy setup into a new private helper in either script. Preserve the existing root-owned socket and Docker cleanup behavior, and do not change src/acme/flow.rs production behavior merely to retrofit its documentation.
Out of scope
Changing certificate renewal behavior, adding fast acceptance coverage, changing the existing red-team attack assertions, or revisiting the unrelated host-port override changes that accompanied the original pull request.
Test plan
Run the repository shell and run-scope validation covering the changed launcher scripts.
Run the registrar red-team scenario through its existing launcher contract.
Run the registrar-endurance case through the extended suite and inspect its case artifact and summary record.
Confirm the LeafWithChain anchor-publication documentation is present in the tree rather than only in the pull-request description, and that it names the [trust].ca_bundle_path gate, the unchanged-root-anchor renewal rationale, and the sole-consumer-today point.
Consolidate registrar scenario setup
Context
The registrar red-team and endurance scenarios both create an isolated live OpenBao/Step CA deployment, but their scripts retain parallel copies of shared deployment and supervisor setup even though
scripts/impl/lib/registrar-docker.shexists for their common launcher support. The endurance work also required a narrow production change:LeafWithChainpublication now adds configured trust anchors that the ACME response lacks, allowing a caller with an unchanged root-anchor pin to reach a renewed registrar endpoint leaf. That behavior was merged without the separate pull-request disclosure required for a production fix exposed by an E2E scenario.Scope
Extract the common registrar live-deployment setup used by
scripts/impl/run-registrar-redteam.shandscripts/impl/run-registrar-endurance.shinto narrowly scoped shared support underscripts/impl/lib/registrar-docker.shor an adjacent shared registrar launcher library. Update both scenarios to use that one implementation while leaving their distinct assertions and workloads local to each script. The run's instance-name derivation is part of that common setup: derive it in the shared helper against the budget the binary validates (MAX_INSTANCE_NAME_LEN,src/commands/compose_project.rs) rather than an endurance-local literal, keeping the name each arm derives today unchanged for every run token either launcher passes. Record the already-mergedLeafWithChainconfigured-anchor publication where it survives review, which is in the tree rather than in a pull-request description. Documentappend_configured_anchors(src/acme/flow.rs:788) beside the function itself or in the registrar reference underdocs/reference/: the[trust].ca_bundle_pathcondition it is gated on, why an unchanged root-anchor pin needs it across leaf renewal, and thatsrc/registrar_certs.rs:122(SURFACE_LEAF_PUBLICATION) is its onlyLeafWithChainconsumer today while any future consumer inherits the behavior, since the change sits in the shared publication arm rather than in registrar-specific code. A pull-request description is not the place for it: that disclosure was owed when #783's pull request merged, and restating it in a later, unrelated pull request buries it where no later reader looks.Acceptance criteria
LeafWithChainanchor publication is documented in the tree, where a later reader will find it — besideappend_configured_anchorsinsrc/acme/flow.rsor in the registrar reference underdocs/reference/— covering the[trust].ca_bundle_pathgate, the unchanged-root-anchor renewal rationale, and thatsrc/registrar_certs.rs:122is its soleLeafWithChainconsumer today with any future consumer inheriting the behavior. A pull-request description does not satisfy this criterion.Constraints
Keep shared support limited to behavior both scenarios genuinely use; do not turn the library into a replacement for either scenario's assertions. Do not copy setup into a new private helper in either script. Preserve the existing root-owned socket and Docker cleanup behavior, and do not change
src/acme/flow.rsproduction behavior merely to retrofit its documentation.Out of scope
Changing certificate renewal behavior, adding fast acceptance coverage, changing the existing red-team attack assertions, or revisiting the unrelated host-port override changes that accompanied the original pull request.
Test plan
LeafWithChainanchor-publication documentation is present in the tree rather than only in the pull-request description, and that it names the[trust].ca_bundle_pathgate, the unchanged-root-anchor renewal rationale, and the sole-consumer-today point.Dependencies
Part of #783. Part of #784.
Pointers
scripts/impl/run-registrar-redteam.shscripts/impl/run-registrar-endurance.shscripts/impl/lib/registrar-docker.shscripts/impl/run-extended-suite.shscripts/validate-e2e-run-scope.shsrc/acme/flow.rssrc/registrar_certs.rs