Skip to content

security(qsfs): read owner mnemonic from MNEMONIC env, not a hard-cod… - #125

Merged
ashraffouda merged 4 commits into
mainfrom
feat/council-driven-migration
Aug 26, 2026
Merged

security(qsfs): read owner mnemonic from MNEMONIC env, not a hard-cod…#125
ashraffouda merged 4 commits into
mainfrom
feat/council-driven-migration

Conversation

@ashraffouda

Copy link
Copy Markdown
Collaborator

…ed const

The qsfs dev script embedded a real sr25519 mnemonic as a package const. Replace it with
os.Getenv("MNEMONIC") and fail fast if unset, so no key ships in the source tree. Rotate
the previously-committed key.

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com### Description

Describe the changes introduced by this PR and what does it affect

Changes

List of changes this PR includes

Related Issues

List of related issues

Checklist

  • Tests included
  • Build pass
  • Documentation
  • Code format and docstring

ashraffouda and others added 4 commits August 23, 2026 23:41
…ed const

The qsfs dev script embedded a real sr25519 mnemonic as a package const. Replace it with
`os.Getenv("MNEMONIC")` and fail fast if unset, so no key ships in the source tree. Rotate
the previously-committed key.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Enables an ops team to relocate a Grade-1 VM using COUNCIL authority instead of the
owner's private key, while the deployment keeps its original owner twin.

The node's chain check already establishes authority: engine.validate() requires the
on-chain contract to name THIS node and its deployment_hash to equal the deployment's
ChallengeHash — and only the council can set those via migrate_node_contract. So for the
migration RMB path we accept a council member (or the owner) as the caller and drop the
owner-signature re-check:

- substrate gateway: GetCouncilMembers() (raw Council.Members storage read) + interface +
  regenerated zbus stub.
- zos_api deployment handlers (transfer / prepare / start): resolve the owner twin from the
  on-chain contract (or the deployment), authorize the RMB caller as the owner OR a current
  council member, and run the per-owner storage ops under the owner twin.
- provision engine PrepareDeployment: no owner-signature Verify (unlike CreateOrUpdate) —
  validate()'s node+hash check is the authority for a migration.

Normal deployment create/update is unchanged (still owner-signed). zos_api_light needs the
same change before council-driven moves work on zos-light nodes (follow-up).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… (get)

Fast-path the owner's own deployment.get (unchanged, no chain lookup); on a miss, resolve
the owner from the on-chain contract and authorize the caller as owner-or-council, so an ops
caller can inspect a deployment it does not own while driving a keyless migration.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Mirror the council-driven migration change into zos_api_light: transfer/prepare/start/get
resolve the owner from the on-chain contract and authorize the RMB caller as owner-or-council
(GetCouncilMembers), so ops can migrate a VM on a zos-light node without the owner's key. The
provision engine's PrepareDeployment (shared) already skips the owner signature on this path.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@ashraffouda
ashraffouda merged commit 7a63627 into main Aug 26, 2026
1 check failed
@ashraffouda
ashraffouda deleted the feat/council-driven-migration branch August 26, 2026 12:36
@ashraffouda
ashraffouda restored the feat/council-driven-migration branch August 26, 2026 12:36
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