refactor(rust): dispose the whole-tree Rust audit corpus - #608
Conversation
owner_key_for listed the entire Zone row set and linear-searched for the owner uid on every Delete and owner-less update. The manager already maintains a uid-to-key index (by_uid); expose it as a KeyForUid RPC on ResourceManagerClient and resolve owners through it instead.
…macro - Add From<&EndpointPolicy> for HandshakeOffer and use it at all seven HandshakeOffer::from(policy.clone()) sites (component_session, session admission/engine/handshake); the by-value impl stays for owned policies. - Add From<&ResourceEnvelope> for ResourceRef in d2b-contracts-resource and use it in ResourceExportSpec::validate_target instead of rebuilding the ref from cloned parts. - Consolidate 28 hand-written Wire-struct Deserialize impls behind a shared wire_deserialize! macro in d2b-contracts-zone-session; wire shapes, defaults, and constructor validation gates are unchanged.
validate_unique_ids and validate_lock_order now return StorageValidationError and SyncValidationError carrying the wire reason and offending id, replacing the String messages that storage_lifecycle re-derived by string-prefix matching. The classifier functions are deleted; the provider-volume-local re-export and its classifier test are dropped.
Mutating-verb response projection now parses the wire outcome into the typed MutatingVerbOutcome vocabulary (new response_outcome_typed accessor) and retarget_mutating_response matches enum variants instead of raw strings, so unknown outcomes fail closed. EstablishedShell hides its Arc<dyn ShellBackend> behind delegating handle_op/close_attachment/cancel_attachment methods; the best_effort_* audit helpers take the shell instead of the trait object. The public read model returns Arc<CachedPublicFrame> from load_list and load_status instead of cloning the whole frame per poll; the wire response clones only at the response boundary. The console drainer runtime static is gone: drainer tasks spawn on the daemon-owned tokio runtime handle passed into the console session creation functions.
The catalog view emitted the committed authz facets as string literals into BrokerAuthzFacets while the sibling authz view emitted the same declared data as typed enums. Emit SecretAccess/BrokerRequirement/AuditMode from the catalog view too, type the BrokerAuthzFacets fields to those enums (re-exported from d2b-core privileges), and align the hand-written test row that drifted case (audit_mode "yes" vs "Yes"). The d2b-core privilege enums gain Copy so the Copy-bearing row structs keep their derives.
…rt doubles The Guest, User, and VolumeBinding test-support doubles each hand-rolled the same recorder shape (a Mutex-guarded Vec<String> call log plus a snapshot accessor) instead of reusing the toolkit's shipped testing module. Ship the shape once as testing::SharedLog and delegate the family recorders onto it; the doubles' public APIs are unchanged.
- Import ZoneId in the security-key, usbip, and network-local driver test modules where the driver-args constructors now parse zones. - d2bd: replace the ? on Result key_ref inside map_err closures with the already-computed device reference (reconcile_tpm) or a hoisted canonical string (finalize_gpu), since those closures do not return Result.
…ter wave-4 merges
CredentialRuntime::dependency_facts now returns Result<Option<CredentialDependencyFacts>, CredentialResourceRuntimeError> instead of Option: a manager RPC failure reaches the driver as Err (DependencyFacts) rather than being logged and answered as absence at the d2bd trait boundary. Ok(None) stays the honest not-committed answer, and the driver fails closed on both. The d2bd log-and-absent workaround is removed; the daemon error detail stays at debug level.
…tion # Conflicts: # docs/audits/2026-09-24-rust-skills-audit/ledger.md
…tion arm The leading comment on the custom Deserialize for AzureVmRecoveryState claimed the legacy fold is total because the write side always sets or clears both values together. Seventy lines below, in the same match, the branch-introduced comment and the Err arm it describes refuse a half-Some pair with a typed serde error. Two comments in one function stated opposite contracts for the same arm, both added by this branch. The claim is also false as written: the total-fold sentence reads as a property of the decode, but the write side is only one of the two ways a record reaches it. The other is a record read back off disk, which the fold is now explicitly told can be malformed. A reader reasoning from the header alone concludes the Err arm is unreachable, treats a decode failure there as an impossible state, and widens the arm back to the total fold this branch removed a panic to break. The sentence is rescoped to the write side, which does hold, and the refusal is stated where the reader will meet it. Only comment text changes; no code, no schema, no generated artifact, no test.
`modern_run` resolves the Zone before it dispatches a command, and `ZoneContext::discover` refuses a command whose public socket does not answer. `host validate`, `host reconcile` and `host doctor` are built with a local-only context and skip that probe; `host prepare` and `host destroy` do not, so their missing-mode refusal - a property of the invocation - was reported as `zone-unavailable` at exit 1 instead of the documented `--apply-or-dry-run-required` envelope at exit 78 whenever d2bd was not listening. The verbs that carry a mode keep their transport refusal, and an explicit `--zone` keeps its routing. The rule now lives in one place, `host::missing_mutation_mode`, which `modern_run` consults before it builds a context; the per-verb copies in `mutation`, `reconcile` and `validate` are gone.
The legacy decode arm refuses a record whose operation and start stamp are only half present, and nothing exercised it. The paired and unpaired records of the same shape decode, so the two controls tie the refusal to the half pair rather than to the record. The enclosing `Repr` is untagged, so the refusal is asserted on the error itself.
`admit_authority` refuses with `StartupRehydrationRequired` until the startup barrier completes, and no test reached that guard. Its only former coverage went with the external-NIC authority surface, while the guard itself stayed on the generic admission path the controller shares the index into, so a caller outside the startup path reached it untested. Distinct from the process-level stage barrier in `main`.
The escape scan ends at the closing brace of the declaring `SeedProvider` block instead of running to the end of the file, and nothing distinguished the two windows. A row written after the block belongs to no provider of its own and is no longer attributed to the preceding one, while a later block is still scanned in its own right.
Review - slice 1 of 2: docs, changelog and planBound to head Verdict: request-changes. Two contract-surface defects in regenerated Finding 1 (blocking) - the v2 storage-lifecycle schema contradicts the bytes the daemon writes
This branch replaced the per-field The schema is produced by Consequence: a consumer validating a real The drift gate does not catch this, because the committed file does equal fresh Finding 2 (major) - the daemon API table documents an in-memory field that never reaches the wire
The regenerated table now lists The next row, Consequence: a reader of the reference writes a client that looks for What this slice checked and cleared
Coverage limitsNo generator, gate or test suite was executed, so this review does not state |
Review - slice 2 of 2: packages, policy and build toolingBound to head Verdict: approve-with-comments. No functional defect, no gate turned green Finding (minor) - a census baseline row is one unit looser than the tree justifies
This branch raises
Consequence: the cap for that crate silently allows one What this slice checked and cleared
On the one red checkThe One point of correction against a claim in the pull request description: the Coverage limitsNo project-wide suite was run, so this review does not confirm that the |
`StorageLifecycleIssue` named its variant fields with serde's container-level `rename_all_fields = "camelCase"`. schemars 0.8.22 reads `rename_all` on a variant, where it renames that variant's fields, but not `rename_all_fields`, so the generated schema required snake_case keys: `bundle_version`, `contract_id`, `offending_id`, and `role_id`. A consumer validating a real report against the committed schema rejected five of the eight issue variants, and the drift gate could not see it because the committed file equalled fresh generator output. Every struct variant now repeats the field casing as a `schemars` attribute, leaving serde's wire bytes untouched, and the schema is regenerated through `make generate`. A new contract test serializes one report carrying every issue variant and validates the bytes against the committed schema instead of against a fresh generator run, so the artifact and the bytes are compared to each other. It refuses a keyword it does not interpret, so a schema that grows one fails rather than passing unvalidated. Against the pre-fix schema the test fails on the first variant that carries a renamed field.
`AuditResponse` holds `entries` and a `page_end`, and its hand-written `Serialize` projects that into the flat `entries`, `nextCursor`, and `complete` keys the protocol has always carried. The response tables read the struct's in-memory fields, so the published row documented a `page_end: AuditPageEnd` member no consumer ever receives. The row now follows the type's hand-written `JsonSchema`, which delegates to the wire struct that publishes the same three keys. A type whose schema delegates is documented from the shape it publishes; every other row still renders its own fields, and the regenerated table differs on that row alone.
…on row The baseline raises `tokio::runtime::Runtime::block_on` from 0 to 1 for `packages/d2b-provider-device`, and a text search of that crate finds no `block_on` at all: a source grep cannot see a `#[tokio::test]` expansion. The census decides the question. Run in its write mode on a clean tree it still reports 1 for that crate, and the crate holds exactly one `#[tokio::test]`, at `tests/device_family.rs:157`. The row is therefore a real counted site, not stale headroom, and it stays. Only the recorded site was wrong: it named `tests/device_family.rs:179`, the closing line of an assertion inside the test and not the attribute the expansion comes from.
Review - slice 1 of 2: docs, changelog and planIndependent Bindings
This evidence binds the head OID above and is not reusable after the head Verdict: request-changes. Three of the four reported findings were Finding 1 (blocking) - a release-bound fragment ends with an internal plan marker
The entry's final parenthetical names an internal planning unit. Refinement to the reviewer's supporting detail: the fragment's unit label is not Finding 2 (blocking) - the plan still points at a removed corpus
The wave-to-cluster appendix derives its counts from a Finding 3 (minor) - a
|
Review - slice 2 of 2: packages, policy and build toolingIndependent Bindings
This evidence binds the head OID above and is not reusable after the head Verdict: request-changes. Four reported findings were re-verified against Finding 1 (blocking) -
|
Internal planning identifiers had leaked into shipped source, config and changelog fragments, and one plan appendix still pointed at a corpus directory that commit 564bd61 removed, so its counts could not be checked from the tree at all. The markers carry no information a reader needs: each reason's technical content stays and only the unit label goes. The plan's appendix now records its own counts instead of citing a path the tree no longer has, and the census fragment states why the device Provider's `block_on` cap is 1 - the single async test expands to that call and the base's suppressive allow is gone - rather than claiming to correct a call-site record the baseline never held. The async-gate doc comment now names the `lock_api` deny-list entries this branch put in place of the `parking_lot` aliases, and deny.toml keeps its duplicate-cluster inventory without naming the audit corpus or carrying a review date.
The `none` role's allowed list was a hand-typed literal naming `realm list` and `realm inspect`, which this branch's parser no longer accepts - the same response told a caller with no role that two retired verbs were allowed while telling a launcher they were not. The daemon half reported those verbs plus `realm enter`, `realm run` and `host check`, none of which the parser declares either, and nothing covered either list, so the drift could not be caught. Both halves now read one shared read-only list of command paths, and a test walks the parser's own command tree to prove every name each half reports resolves to a declared subcommand. A retired verb reintroduced on either side fails that test. The daemon API reference and the async-gate inventory are regenerated through their owning tools, so their line anchors follow the moved types and marker sites.
Review - slice 1 of 2: docs, changelog and planBindings
This evidence binds the head OID above and is not reusable after the head changes. It supersedes the slice 1 record bound to head Verdict: approve-with-comments. Scope is exactly Prior items re-derived at this headThe three findings reported at head
Findings1. (minor) One of three statements about the relay settings schema was corrected; two were left, and now contradict it
The patch rewrote the Two other statements in the same file were left:
Evidence that the surviving claim is false against the committed head: Before the patch all three locations made the same (false) claim, so the file was at least internally consistent. Correcting one and leaving two is what makes the contradiction new, and it is the same stale-pointer class the patch set out to sweep. The corrected text at lines 198-203 is itself accurate and I verified it end to end: Impact: the work item tells a maintainer that a drift gate protects an artifact the same file now says is hand-authored and embedded, and a maintainer who runs the named command gets an unknown-subcommand error. Fix: drop the drift-gate sentence at 1369-1371, keeping the "committed, version-controlled" wording and the derivation-copy paragraph below it, and remove the generator clause from the two work-item rows at 1464-1465. If the generation is genuinely planned rather than done, mark it as planned instead of stating it as an integration that exists. 2. (minor) The plan still tells a reader the audit corpus directory is untracked; the tree has no such directory
The Evidence against the committed head: Impact: a reader picking the plan up for the follow-up work its Scope Boundaries defers to will look for a directory the repository does not contain, and the U1 verification step can never pass. This is the identical failure the appendix was corrected for in the same commit, and that sweep stopped one section short. Fix: rewrite the assumption to say the corpus is not part of the shipped tree, and mark the U1 corpus-commit step as already reverted by 3. (nit) The rename-map table header still schedules the V3 column at v1.1.1
The patch rewrote the status note at lines 212-215 so that it says the V3 wire schema "ships with the emit-side flip, scheduled for v1.1.2". Fifteen lines below, the rename-map table header at line 231 still labels its second column "V3 field (wire-side, v1.1.1+)", and the section heading at line 222 already reads "v1.1.1 SHIPPED -> CLI-emit at v1.1.2 rename map". The block the patch rewrote is now internally inconsistent about when V3 exists. This inconsistency predates the patch in form, but the patch restated the schedule directly above the table and left the header alone, so the block it just corrected still carries a schedule a reader would act on. Fix: change the column header to "V3 field (wire-side, v1.1.2+)". What this slice checked and cleared
RefutedRecorded because each looked like a defect from a text search and each was disproved against the committed head, which is the failure mode this slice is most exposed to.
CoverageExamined: all 29 Not examined: the factual accuracy of the prose inside all 165 fragment bodies (grammar was checked exhaustively; content claims were spot-verified on the entries tied to the head-moving commits, the branch fragment, and the ADR-046 and relay spec edits); whether the generators emit byte-identical output, which needs the drift gate; the four lanes of the gate and any other build, test or lint; |
Review - slice 2 of 2: packages, policy and build toolingSupersedes the prior slice-2 record bound to head
Verdict: approve-with-comments. Grounding held: The head commit Findings1. Blocking-API baseline caps record the test-inclusive count, so this patch raises a production crate's
|
The committed Provider signature verified at 88f13fc, d3e58b3, and 0d2a5bc and broke at 2ca9a22, which moved root-config.schema.json and updated the manifest configDigest without re-signing. The old private key is not recoverable, so rotate the publisher keypair rather than re-derive the old one: publisher-public-key.pem carries the new SPKI public key and provider-manifest.json.sig is a fresh raw 64-byte Ed25519 signature over the current manifest bytes. The manifest is byte-for-byte unchanged; only the signature and the public key move. The operator holds the private half outside the repository. Nothing caught the staleness because the Nix build only asserts that the sidecar is 64 bytes long. Add a hermetic test in the resource compiler that loads the committed manifest, sidecar, and public key and asserts the signature verifies over the manifest, with a probe for each half moving alone, so a later manifest or schema change that forgets to re-sign fails the check lane instead of shipping. The test reads the trio from the runfiles tree, and the trio is declared as test data so Bazel re-runs it when any of the three files changes.
Review - slice 1 of 2: docs, changelog and planScope: exactly the 195 files under Bindings
Verdict: Required question 1 - the new signature changelog fragment
No key material is exposed. The fragment names only the two public artifacts ( Fragment format is compliant with Required question 2 - documentation drift under docs/No file under This branch also removes real drift rather than adding it, and each removal was checked against committed code:
Planning, revision, follow-up and finding markers. The branch adds no marker to any shipped doc. A scan of all 166 new changelog fragments' contents for audit identifiers ( Required question 3 - regenerated reference material against committed codeThe v2 storage-lifecycle casing defect is genuinely fixed. The same defect class is not present in the sibling v2/v3 schema pairs.
Required question 4 - paths, targets, counts and commandsCovered by finding 2 (three nonexistent source paths) and finding 1 (a nonexistent command named three times). All other named targets in the slice resolve at this head: the 63 path-like tokens in the new plan were each checked against the committed tree, as were every relative link in the 13 changed markdown files, and the Findings1. The same file still names a command that does not resolve, in three places the branch left behind
Defect: line 1369-1371 still says the committed settings schema "is committed, version-controlled, and kept in sync with the Rust Evidence: at the reviewed head the subcommand dispatch in Fix: delete the 2. The new plan names three source files that do not exist at the reviewed head
Defect: the unit U1 "Files" list names Evidence: the committed tree at the reviewed head places the first at Fix: correct the three entries to 3. The new changelog fragment asserts a record that is not present
Defect: the fragment says "the operator holds the new private half outside the repository, and only its location and public fingerprint are recorded here", and the next sentence instructs consumers that they "must trust the new public key before building a Zone that installs this artifact". The fragment records neither a location nor a fingerprint, so the sentence describes a record that does not exist and the pinning instruction gives the reader nothing to pin. Evidence: the fragment is 26 lines and contains no fingerprint string and no private-key location; the only paths it names are the two public artifacts. The committed key at the reviewed head, Fix: either add the public-key fingerprint and the committed public-key path, or delete the "and only its location and public fingerprint are recorded here" clause and point readers at 4. The new plan describes
|
Reconciliation of the two slice reviews bound to
|
Review - slice 2 of 2: packages, policy and build toolingBindings
Verdict: approve. No finding in this slice met the bar of provable impact plus a discrete fix. Slice 2 covers every non- 1. Manifest untouched by the rotationConfirmed, and it is the load-bearing check for this commit.
The manifest is a different blob at the pull request base ( Related consistency check I also ran, because the commit message names the schema as part of the failure: the manifest's 2. Public key replaced, not added; sidecar is 64 raw bytes
3. No private key material, in the tree or in the range
4. The new test, read in full
5. Bazel wiring, and consumers of the rotated key
6. Regressions across the sliceNothing provable. What I checked and cleared:
FindingsNone. No defect in this slice met the bar of provable impact, a discrete fix, and introduction by this pull request. RefutedCandidates I raised and disproved against the committed head, one line each:
|
The Azure Relay ADR named an `xtask gen-provider-transport-schemas` subcommand in three places and a `make test-drift` gate built on it. No such subcommand exists and the suite that target resolves to does not cover this file; the same ADR already states the schema is hand-authored and embedded verbatim, so the file contradicted itself. Cite the embed and the crate test that pins the schema instead, and use the real type name `RelayTransportSettings`, which the same ADR already uses elsewhere. The remediation plan listed three finding sites under paths that do not resolve, and described the `labs/` tree as retired while the head carries 171 tracked files under it, its own governing `AGENTS.md`, and a live prototype. Correct the paths and describe the tree as live. The signature fragment promised a location and a public fingerprint and recorded neither, and the fold copies the line into released prose. Drop the location claim and record the public fingerprint with the convention that produces it, so a reader can recompute it and pin the key.
87b82cf to
05092a6
Compare
The persistence fixtures passed a literal 7 as the prepared nonce, which the code-scanning rule reads as a hard-coded cryptographic value. Both fixtures now derive the nonce through the crate's existing test_nonce_for_operation helper, widened to the crate for reuse from the persistence tests. The rejection test keeps its literal inputs: zero and a valid control are the values under test there.
The Guest workspace mirror did not declare the `tracing` dependency the bundle resolver uses, so the static Guest build and the container lane failed compiling `d2b-core`; the fixture override and the Guest lock now carry it, and `tests/tools/guest-workspace-drift.py` is clean again. Applies the fresh review's findings as well: the seccomp-profile re-export list regains the four public items it dropped (the error type its public methods return and the three enforcement bounds), the eight documents that still cite the deleted `d2b-core` compat shim modules are re-pointed at `d2b-contracts`, the plan accounts for all thirteen `high` rows in its wave-0 disposition, and the broker transport's audit-join refusal describes itself accurately with its tautological test and now-unused helper removed.
|
Bound to head Review - slice 1 of 3: docs/ and changelog.d/
Method: read-only. Findings1. Live docs still cite the six
|
|
Bound to head Review - slice 2 of 3: daemon, control-plane, contracts, runtime and build-toolingBindings
Method: read the scoped diff, then read the tree at both revisions for every candidate - the base side via Findings1.
|
|
Bound to head Review - slice 3 of 3: Provider and prototype sideBindings
MethodRead Findings1. Provider manifest trust and compatibility admission lost its only production callerLocation. Defect.
Evidence.
Impact. A cryptographically authentic signed Provider manifest whose Fix. Restore an admission call on the production path: in 2. seccomp-profile dropped four public items, including the error type its public methods returnLocation. Defect. The wildcard Evidence.
Fix. Add the four omitted names to the Verdictrequest-changes Finding 1 removes a live refusal path together with the test that pinned it, and leaves a doc comment asserting an enforcement that no component performs. Finding 2 is an unnameable error type in a confinement contract crate. Both are small, discrete fixes. ReconciliationCandidates examined and dismissed, with the evidence that dismissed each. Several are the areas this slice was most asked to look hardest at, and several are genuinely clean.
Limits of this reviewI verified the code and the committed artifacts directly. I did not run the build, linters or test suites, per the review constraints, so I make no claim about whether the workspace currently compiles; a consequence is that findings 1 and 2 are argued from the export surface, call graph and enum/visibility structure rather than from a compiler diagnostic. A sub-investigation into privilege, namespace and device-mediation boundaries reported that the per-provider crates in this slice are declarative - they name a seccomp policy reference, a namespace set and a device-bind list rather than installing confinement, which lives in |
Adding the mirror's `tracing` dependency moved `packages/Cargo.guest.lock`, so the committed guest-static policy inputs recorded a stale `lockSha256` and the drift gate failed; regenerated through `make generate`, which also emits the new `d2b-core -> tracing` closure edge. The storage-lifecycle schema test now compares the issue kinds its fixtures exercise against the kinds the published schema declares, instead of asserting the length of the literal list it just built, and the auth-status contract's module doc no longer says the launcher gains `up`.
The plan still made committing the audit corpus a wave-0 requirement in its wave map, its assumptions, and U1's heading, approach step and verification, while the same document's R8 and Definition of Done state that the record does not ship and the corpus was deliberately dropped from the tree. Those steps now read as the ledger and baseline work they are. Alongside it: the USBIP lock-taxonomy fragment quotes the three real `device-worker-*` refusal codes instead of truncated tails, the parking-lot fragment names the bounded-worker allow reason instead of a plan identifier, and the v1.0-to-v1.1 migration guide's table header matches the v1.1.2 arrival its own note records.
What this is
A repository-wide Rust audit of the whole tree, and the remediation of every
finding it produced. The work is a static-analysis sweep of the Rust workspace
across ten lenses (idiom, type, api, err, docs, perf, async, unsafe, test,
supply), applied as a series of small, separately-reasoned changes rather than
one sweeping rewrite, and recorded row by row in
docs/audits/2026-09-24-rust-skills-audit/.Head:
e1c7e85d576301e4e84cdcaf784555fd9b0ca043. Observed base:v3at133b78fc49c6ca101aaa573c87a5884adad74cb7.Provider publisher key rotation
The head commit rotates the cloud hypervisor Provider publisher keypair. The
committed signature verified at
88f13fc1e,d3e58b328and0d2a5bc17andbroke at
2ca9a22dd, which movedroot-config.schema.jsonand updated themanifest
configDigestwithout re-signing, leaving the compiler refusing theartifact. The previous private key is not recoverable, so the keypair is
rotated rather than re-derived.
packages/d2b-provider-guest-cloud-hypervisor/provider-manifest.jsonisbyte-for-byte unchanged (blob OID identical on both sides of the commit).
publisher-public-key.pemis modified, not added: it carries the new SPKIEd25519 public key.
provider-manifest.json.sigis modified, not added: a fresh raw 64-byteEd25519 signature over the current manifest bytes.
private key in the tree at this head, none in any commit in this pull
request's range, and no private-key location recorded anywhere in it. The
operator holds the private half outside the repository, and the manifest,
the sidecar and the public key are the only key-related bytes in the change.
suites mint their own ephemeral keypairs at test time.
Verified independently of the repository's own code with OpenSSL against the
committed bytes:
openssl pkeyutl -verify -pubin -rawinoverprovider-manifest.jsonwithprovider-manifest.json.sigandpublisher-public-key.pemreturnsSignature Verified Successfully; aone-byte change to the manifest and the old public key against the new
signature both return
Signature Verification Failure.A hermetic test,
committed_artifact_signature_verifies_over_the_committed_manifestin
packages/d2b-resource-compiler/src/lib.rs, now pins the pair in theLayer-1
make checkaggregate: it loads the trio from the Bazel runfiles tree,asserts the committed signature verifies over the committed manifest through
the production
verify_ed25519path, and probes that a manifest or a signaturemoving alone does not verify. The trio is declared as test data on both
unit-test targets in
packages/d2b-resource-compiler/BUILD.bazel, so Bazelre-runs the test when any of the three files changes. It ran and passed in
this head's
checklane:test tests::committed_artifact_signature_verifies_over_the_committed_manifest ... okin the
//packages/d2b-resource-compiler:d2b_resource_compiler_testtargetlog, 9 passed, 0 failed. The Nix build only asserted the sidecar was 64 bytes
long (
nix/provider-artifact.nix:135), which is why the staleness shipped.Scope of the change
1092 files changed, +40842 / -22925: 718 Rust sources across the workspace,
the
Cargo.tomlandBUILD.bazelfor each crate, regenerated supply-chainpolicy inputs, the
deny.toml/clippy.toml/flake.nixpolicy surface,166 new
changelog.d/fragments, and the regenerated reference schemas anddocs. Work landed in seven waves (U1-U3, W3-W7), each dispatched as parallel
slices, merged, and gated.
Relationship to the base
This branch merges onto a
v3that has just landed a separate unit-test auditremoving 197 redundant unit tests (base commit
133b78fc4, pull request #607).That is why test counts read differently in different places across this
history, and it is expected rather than a regression: the two audits removed
different things from the same crates.
Validation
Four-lane gate, green on this head
Run on head
e1c7e85d5in the gates worktree at the pull request's standardscan base
542920db8. All four lanes exited zero. Each lane's raw summary,from its own log:
tests/tools/security-scan.shsecurity-scan: clean (changed in-tree Rust lines since the merge base 542920db8eb94293734f0954c3ec01f863fc3d28)make check-censuscrates censused: 94,blocking-census check: PASS (no crate above its committed baseline), 65 entry classes at or below baseline per cratemake checkExecuted 6 out of 1023 tests: 1023 tests passmake test-host-integrationThe scan base is
542920db8rather than the fixer's5001d7b26: theidentifier-in-log redaction rule scans the added lines of the diff from the
merge base, so the wider base is the superset and the one this pull request
has used throughout.
Required checks
The required contexts on
v3areeval,checkandsecurity-scan. Allthree pass on this head, read from the check runs recorded on
e1c7e85d576301e4e84cdcaf784555fd9b0ca043itself:evalchecksecurity-scancheckis the aggregate job inpr-l1-static-fast.ymland reported only onceits eleven upstream suites finished; it turned green at 14:28:44Z on this head.
Of the eighteen contexts on this head, seventeen pass. The one exception is
not a required context and is recorded below.
Known residuals
These are known and deliberately left. Each is stated with what was actually
measured.
CodeQLreports one criticalalert,
packages/d2b-core-controller/src/authority_persistence.rs:375,"This hard-coded value is used as a nonce." It is a false positive,
verified at this head: the
#[cfg(test)] mod testsblock begins at line337, and the literal
7at line 375 is thenonceargument ofPreparedAuthorityOperation::newused to build deterministic test data. Theproduction path mints its own non-zero value.
CodeQLis not a requiredcontext, so it does not block the merge; it is recorded here rather than
suppressed.
changelog-foldis a merge-time step, not a pull-request gate. Thisbranch does not modify
CHANGELOG.md, so the pre-existing fold-timedefects in the changelog history recorded in earlier rounds are untouched
by it. The one fragment this branch adds is structurally validated by
//packages/xtask:policy_changelog_gate, which passes in this head'schecklane.packages/d2b-broker/src/ops/host_generation_handoff.rs:265and:268mapthe
try_sendand oneshot-receive failures onto genericio::Errorstrings ("handoff lock worker busy" / "handoff lock worker unavailable").
The refusal is forwarded, but the originating variant - a full queue
versus a closed one, or a worker that dropped the reply - is not carried
with it, so the two failure modes are indistinguishable to a caller. This
is a diagnosability gap, not a correctness defect, and it is unchanged at
this head.
four-lane gate of its own, at
d68d0dbc(an ancestor of this head); anearlier wave-3 gate run at
d322db6c8was red and was superseded by it.Wave 7's close record carries a five-command preflight rather than a
four-lane gate, and records its wave-gate cells as not run, the four-lane
gate being run centrally. Both wave close records live in gitignored
scratch directories and are therefore not part of the committed tree; the
evidence for the current head is the gate run in the Validation section
above.
Review
The change is reviewed in two slices, each by a separate review in its own
clean context, bound to head
e1c7e85d5against base133b78fc4:docs/, 166 underchangelog.d/)Each review's binding table, findings and verdict are recorded as a comment
on this pull request, together with a reconciliation of every candidate
against the committed head. Neither record is reusable after the head moves.
The packages, policy and build-tooling slice returned approve with no
finding. The docs, changelog and plan slice returned request-changes with
four findings, all documentation-only and all verified against this head:
docs/specs/providers/ADR-046-provider-transport-azure-relay.md:1369-1371(and
:1464,:1465) still name thextask gen-provider-transport-schemassubcommand and the Rust type
AzureRelayTransportSettings. Neither exists;the same file already says at
:198-203that the schema is hand-authored,so the file contradicts itself.
docs/plans/2026-09-24-002-refactor-rust-skills-remediation-plan.md:151names three source paths that do not resolve; the committed tree carries
them one directory up, and under
wayland_proxy/.changelog.d/fix-provider-artifact-signature.md:13-15states that the newkey's location and public fingerprint are recorded in the fragment, and
records neither. The fragment exposes no key material either way; the
defect is that the clause describes a record that is not there and the
fold copies it verbatim into the released changelog.
docs/plans/2026-09-24-002-refactor-rust-skills-remediation-plan.md:71defers "the retired
labs/tree"; the head carries 171 tracked filesthere and the repository treats it as live.
None is acted on at this head: a fix moves the head and would invalidate both
review records, so the pull request is not merge-ready until these are
fixed and the head is re-gated and re-reviewed.