Skip to content

forkidentity: drop a per-fork identity record into every fork#217

Draft
sjmiller609 wants to merge 1 commit intomainfrom
hypeship/fork-identity-hardening
Draft

forkidentity: drop a per-fork identity record into every fork#217
sjmiller609 wants to merge 1 commit intomainfrom
hypeship/fork-identity-hardening

Conversation

@sjmiller609
Copy link
Copy Markdown
Collaborator

Summary

  • New lib/forkidentity package: Build(forkID) produces an identity with 256 bytes of crypto-rand entropy + a small forward clock jitter; Write(dir, id) atomically writes fork-identity.json into the fork's data directory; Read(dir) loads it.
  • Wires writeForkIdentity into forkInstanceFromStoppedOrStandby so every fork drops a fresh record before metadata save.
  • Failure is fatal — identity reuse is a security regression, not a soft warning.

Why

When N forks come up off the same restored memory snapshot they share /dev/urandom state, machine-id, hostname, and clock. That silently breaks crypto (TLS keys, JWTs) and makes fan-out forks indistinguishable to operators. Hypeman can't safely rewrite guest state directly, but it can plant a small record that a guest agent (separate work) reads at boot to reseed /dev/urandom, refresh machine-id, and step the clock by ClockOffsetNs.

Test plan

  • go test ./lib/forkidentity/...
  • go test ./lib/instances/... -run "TestForkInstance|TestValidateFork|TestForkRequest"
  • Manual: fork a Standby instance, confirm <fork>/fork-identity.json exists, has version: 1, has 256-byte entropy_seed, and a small clock_offset_ns
  • Manual: fork twice, confirm seeds differ

🤖 Generated with Claude Code

When N forks come up off the same restored memory snapshot they share
/dev/urandom state, machine-id, hostname, and clock — which silently
breaks crypto and makes fan-out forks indistinguishable.

This change adds lib/forkidentity, a small package that produces a
fresh per-fork record (256 bytes of crypto-rand entropy plus a small
forward clock jitter) and atomically writes it as fork-identity.json
into the fork's data directory. forkInstanceFromStoppedOrStandby now
calls it on every fork before metadata save.

The hypervisor side never touches guest state. A future guest-agent
change reads this file at boot and applies it: reseeds /dev/urandom,
refreshes machine-id, and steps the clock by ClockOffsetNs. Failure to
build/write the record is fatal because identity reuse is a security
regression, not a soft warning.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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