Expose migration intent bucket name in runtime info response

[chris-ricketts]

Why

Verifiers and observers of the public migration intent log need to link the log to the deployment they are verifying. Previously, they could not establish that a public bucket advertised out of band by the operator was the bucket actually used by that deployment.

How

Expose migration_intent_bucket in the GET /enclave/v1/info response. The value is the bucket used by the migrator, derived from the AWS account ID returned by STS, the deployment name and the app name.

A client that verifies the enclave’s attestation and pins the attested TLS public key can trust that the reported bucket is the migration intent bucket committed in the deployment’s state root. This links the public log to the deployment identified by the TLS public key hash.

The migrator retains the resolved bucket name and exposes it through MigrationIntentBucket() for the runtime info handler.

Tests

1. Extend the runtime info handler test to assert the reported bucket name.
2. Extend QEMU end-to-end assertions to check the bucket on initial nodes, a migration candidate, the promoted node and a restarted peer.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[arkana-ai-bot]

Review

Scope: additive informational field on a read-only public endpoint. No migration state machine, signing, key-export, or forfeit paths are touched.

---

Correctness

**** — is a straightforward getter backed by , which is set once at construction from the argument. Nothing mutates it, and nothing in the migration state machine reads it, so it is purely observational. ✓

One cosmetic note: and (the field on , used in at via the ) are two copies of the same string, both initialised from the same constructor argument. The PR could have exposed directly to avoid the copy, but having both is harmless since they share an origin and neither is mutated.

**** — is populated synchronously from the getter with no error path; the value is stable for the lifetime of the migrator. Additive JSON field — fully backward-compatible. ✓

**** — now satisfies the updated interface. 's helper is extended to include , so all three assertions in that test exercise the new field. uses the mock but only asserts on and ; the bucket flows through but isn't checked — acceptable given that test's focus. ✓

**** — is defined in as:

This exactly mirrors in :

Four checkpoints are asserted: initial blue nodes (genesis), green as candidate, promoted green, restarted green_peer. The assertions not updated (blues reporting intent toward green, blue after restart) are checking unrelated subfields of the response — no gap there. ✓

---

Security

The bucket name is derived from the AWS account ID, deployment name, and app name. It contains no key material, credentials, or cryptographic secrets. Exposing it via the public info endpoint is the stated purpose: it allows a verifier who has pinned the attested TLS key to bind that key to a specific migration log without the operator having to claim the binding out-of-band. No auth bypass or information-disclosure concern. ✓

---

Cross-repo impact

No other repo clones under import or consume directly; the endpoint is consumed by tooling and scripts, not by a shared library. The change is additive (new JSON key, existing keys unchanged), so any existing client deserialising the response is unaffected. ✓

---

Minor documentation gap

line 517 describes the response but doesn't mention . Worth a one-line addition in a follow-up (e.g. "and the migration intent bucket name linking this deployment to its public log"), but not a blocker.

---

No blocking issues found.

[arkana-ai-bot]

Review

Scope: additive informational field on a read-only public endpoint. No migration state machine, signing, key-export, or forfeit paths are touched.

---

Correctness

runtime/migrate.go — MigrationIntentBucket() is a straightforward getter backed by m.bucket, set once at construction from the migrationIntentBucketName argument. Nothing mutates it post-construction, and nothing in the migration state machine reads it, so it is purely observational.

One cosmetic note: m.bucket and m.intent.bucket (the field on migrationIntentLog, consumed in handOffToSuccessor via the bootSnapshot) are two copies of the same string, both initialised from the same constructor argument. The PR could have exposed m.intent.bucket directly, but having both is harmless since they share an origin and neither is mutated after construction.

runtime/servers.go — MigrationIntentBucket is populated synchronously from the getter with no error path; the value is stable for the lifetime of the migrator. Additive JSON field — fully backward-compatible.

runtime/servers_test.go — migrationControlMigrator now satisfies the updated Migrator interface. TestConfigureEnclaveInfoHandler's want() helper is extended to include MigrationIntentBucket: migrationIntentTestBucket, so all three require.JSONEq assertions in that test exercise the new field. TestConfigureEnclaveInfoHandlerReportsInboundHandoff uses the mock but only asserts on Status and Candidate; the bucket flows through but is not checked — acceptable given that test's focus.

nix/tests/e2e.py — INTENT_BUCKET is defined in helpers.py as sha256("dev\x00testapp")[:8].hex() prefixed with the account ID, which exactly mirrors migrationIntentBucketName in migration_intent.go. Four checkpoints are asserted: initial blue nodes (genesis), green as a candidate, promoted green, and restarted green_peer. The assertions that were not updated check unrelated subfields of the response — no gap.

---

Security

The bucket name derives from the AWS account ID, deployment name, and app name. It contains no key material, credentials, or cryptographic secrets. Exposing it via the public info endpoint is the stated purpose: a verifier who has pinned the attested TLS key can bind that key to a specific migration intent log without relying on an out-of-band operator claim. No auth bypass or key-disclosure concern.

---

Cross-repo impact

No other repo clones under /srv/arkana/repos import or consume RuntimeInfo directly. The change is additive (new JSON key, existing keys unchanged), so any existing client deserialising the response is unaffected.

---

Minor documentation gap (non-blocking)

README.md line 517 describes the /enclave/v1/info response but does not mention migration_intent_bucket. A one-line addition (e.g. "and the migration intent bucket name linking this deployment to its public log") would keep the docs current, but this is not a blocker.

---

No blocking issues found.