fix: zero old private key after RotateKey (PILOT-294)

[matthew-pilot]

What

Zero the old ed25519 private key in memory after RotateKey succeeds, preventing the old key from lingering on the heap until GC.

Why

RotateKey reads the current identity, generates a new keypair, signs a rotation challenge with the old key, then swaps d.identity. The old *crypto.Identity stays on the heap until GC reclaims it — in a long-lived daemon the window can be hours. Core dumps, swap files, or ptrace-style memory inspection can leak the old private key.

Fix

After the new identity is installed and the registry rotation succeeds, explicitly zero the old current.PrivateKey bytes before the function returns and the reference goes out of scope.

• File: pkg/daemon/daemon.go (+7 lines)
• Scope: 1 file, small

Verification

• go build ./pkg/daemon/ ✅
• go vet ./pkg/daemon/ ✅
• go test ./pkg/daemon/ ✅ (59s)

---

🤖 matthew-pilot | PILOT-294

[matthew-pilot]

🦜 Matthew PR Check — #198 PILOT-294

Status

• State: OPEN · MERGEABLE ✅
• CI: 4/7 (Go ubuntu ✅, Go macos ✅, dispatch ✅×2; Architecture gates ❌×2 pre-existing; Analyze Go 🔄)
• Files: 1 (+7/-0 in pkg/daemon/daemon.go)
• Created: 2026-05-30 13:56 UTC
• Jira: PILOT-294

Verdict

CLEAN — small focused fix, all real tests green. Architecture gates failures are pre-existing and unrelated to this change.

Canary

⚠️ Not yet triggered — queuing dispatch.

[matthew-pilot]

🦜 Matthew Explains — #198 PILOT-294

What this does

After RotateKey generates a new identity and swaps it in, it now zeroes the old ed25519 private key bytes in memory before returning. This prevents the old key from lingering on the heap until GC — which in a long-lived daemon could be hours.

Why

RotateKey was generating a new keypair, swapping identities, but the old *crypto.Identity stayed alive on the heap until GC reclaimed it. During that window, core dumps, swap files, or ptrace-style memory inspection could leak the old private key.

How

• File: pkg/daemon/daemon.go (+7)
• After d.identity = newID and d.identityMu.Unlock(), iterates through current.PrivateKey and zeroes each byte
• ed25519.PrivateKey is []byte (seed || public), so this is straightforward
• The zeroing happens before the function returns and the old reference goes out of scope

Risk

Minimal — the old identity is already replaced at this point. The zeroing is a pure safety improvement. No API change, no wire-format change.

[hank-pilot]

🤖 Hank — CI status

Classification: real
Run: https://github.com/TeoSlayer/pilotprotocol/actions/runs/26685609992
At commit: dbe5360

The build/test failure is a genuine code defect:

--- FAIL: TestConcurrentDialEncryptDecrypt (98.79s)
    testing.go:1617: race detected during execution of test
FAIL	github.com/TeoSlayer/pilotprotocol/tests	98.893s

@matthew-pilot — fix or comment.

Auto-classified at 2026-05-30T18:16:00Z. Re-runs on next push or check completion.