Files
felhom.eu/REPORT.md
T
admin 0c843286a2 slice 10B: signed-op job completion (DELETE clear-job) (hub v0.10.0)
Add DELETE /hosts/{id}/jobs/{job_id} (per-host self-scoped, idempotent) so the
agent clears a job after executing or terminally rejecting it. The hub stores
the operator-signed blobs opaquely (no signing key — cannot forge or open);
the agent verifies + executes. Doc 03 §4/§6/§9 updated (operator-signed path
live; 8C wipe completes; 10B done).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-10 20:14:32 +02:00

2.3 KiB

felhom.eu — task reports

Overwrite this file with a summary of the most recent task only (uniform with the other repos; not cumulative). The cumulative hub history lives in hub/CHANGELOG.md.


REPORT — Slice 10B (hub half): signed-op job completion (hub v0.10.0) (2026-06-10)

Type

TASK (CC-implemented). The hub half of slice 10B. Pairs with felhom-agent v0.16.0 (the signing CLI

  • verify-and-execute machinery + the storage-wipe consumer).

What changed (hub)

Small by design — the hub stores + serves the operator-signed blobs opaquely (it holds no signing key, can neither forge nor open them; the agent verifies + executes). 10B adds the completion path.

Store + API

  • DELETE /api/v1/hosts/{host_id}/jobs/{job_id} (per-host key, self-scoped; global key may clear any) — the agent calls it after executing OR terminally rejecting a job. Idempotent. Store: DeleteSignedJob.
  • Reused unchanged from 10A: POST /admin/hosts/{id}/jobs (operator enqueue), GET /hosts/{id}/jobs (agent fetch), has_signed_ops envelope flag. The signed blob stays opaque on the wire (a base64 {op_blob_b64, sig_armored} envelope) — no jobs-wire golden change.

Tests (green)

  • DELETE …/jobs/{id} self-scoped (host A cannot clear host B's job → 403) + idempotent.

Docs

  • Doc 03 §4 (the operator-signed path is LIVE: gate → pending op → offline signature → verify (pinned key / nonce-burn / expiry / host + durable-id anti-retarget) → execute; key floor: not in the hub, not in the agent), §6 (the 8C data-bearing wipe now completes via 10B), §9 slice table (10B done; 10C escrow-consumption spike-validated, 10D DR capstone pending).

Security framing (why the hub stays minimal)

The hub is deliberately a dumb queue here: it cannot forge a signed op (no key) and the agent never trusts a queued blob until the pinned-key verify passes. A compromised hub queuing a forged blob is rejected by the agent (tested in felhom-agent). That is the whole point of the offline-key design.

Pending

  • Build + deploy hub v0.10.0 (+ agent v0.16.0) and live-validate the full loop on the demo: a data-bearing wipe → pending_signature → offline-signed → queued → agent verifies + wipes the device; replay + non-pinned-key rejected.