felhom-agent/REPORT.md

REPORT — agent v0.79.0: SLICE 3 escrow upload carries the sealed password's hash — DEPLOYED

Date: 2026-07-09 · Class: implementation (agent, small). Baseline v0.78.0 → v0.79.0, live on felhom-pve (felhom-agent 0.79.0, capabilities self-check 56/56, degraded=0). The hub-verified escrow auto-confirm chain, agent third — pairs with hub v0.40.0 (stores + serves) and controller v0.108.0 (matches + auto-confirms). All three deployed live.

What shipped

• internal/escrow.HashResticPassword — the CANONICAL hasher: sha256 hex over the TRIMMED password string, exactly the value AttachResticPassword seals into the identity blob. Pinned cross-repo test vector (TestHashResticPassword_PinnedVector — the identical vector is asserted in felhom-controller's backup package), so the two hashers can never drift silently (newline/encoding/trim).
• cmd/felhom-agent: the escrow-create ceremony computes the hash when a staged password is folded in and includes it in the blob upload — escrowUploadRequest.restic_pw_sha256,omitempty. No staged password → field OMITTED (hub stores NULL → the controller stays pending; correct — the blob doesn't cover the key). The hash of a 256-bit random secret is non-reversible — safe to upload/serve; the password itself is never logged or uploaded in the clear (it rides only inside the R-wrapped blob, as before).
• TestEscrowUploadContract updated in lockstep with the hub's mirror (same commit-pair) + asserts the omitted-when-unstaged behavior.
• Ceremony flow (create / self-verify / R banner / staged-file wipe) untouched beyond the hash.

NOT yet live-exercised

A real ceremony with a staged password recording the hash — happens at the next real offsite enable (Peti onboarding). The demo's escrow row remains a legacy NULL-hash blob (covered by the deprecated manual confirm; verified live that the controller no-ops on it).

Deploy

Standard: built on 180, .bak-0.78.0 kept, install -m0755 + restart. configs/ unchanged. NOT published to Gitea (Day-0 manifest still vouches 0.76.0).