#237 peering delivery: encrypt to the recipient (v0.6.23) #239

Merged

Cordy merged 2 commits from feat/237-deliver-recipient into main

2026-08-15 13:25:35 +00:00

Cordy commented

2026-08-15 13:23:50 +00:00

Owner

Fixes the delivery blocker found in the 2026-08-14 A↔B dogfood: a real transfer failed with encrypt: no authenticated user in context because FileDeliverer.Deliver wrote the plaintext through the full decorated storage stack with the raw CompleteTransfer RPC context — which has no user — so the per-user encryption decorator had no key to encrypt to.

Option A from the #237 deep-dive: populate the recipient into the delivery context.

ctx = auth.ContextWithUser(ctx, &auth.User{Username: tr.Recipient})

The encrypt decorator then resolves the recipient's key by username via the custody backend's admin/app credentials (the identical path the crypto role already uses for X-Cairn-User), re-encrypting the file to the recipient's own key + deployment recovery. Consequences are all correct: counted against the recipient's quota, subject to their holds, written to /home/<recipient>/Inbox (personal → user key), lazily provisions a key for a never-logged-in resident recipient (which also closes the #123 resident-vs-key gap), and works unchanged in-process and against a --target=crypto replica. Not a patch — the deliverer was already built to "write through the full stack as the recipient"; the context population was simply missing.

Test: TestDeliverWritesAsTheRecipient asserts the write context carries the recipient (hades123). Full go build/vet/test ./internal/peering/... green on the runner.

Closes #237. Clears the delivery blocker for #106; E2E follow-up tracked in #238.

Fixes the delivery blocker found in the 2026-08-14 A↔B dogfood: a real transfer failed with `encrypt: no authenticated user in context` because `FileDeliverer.Deliver` wrote the plaintext through the full decorated storage stack with the raw `CompleteTransfer` RPC context — which has no user — so the per-user encryption decorator had no key to encrypt to. Option A from the #237 deep-dive: populate the recipient into the delivery context. ```go ctx = auth.ContextWithUser(ctx, &auth.User{Username: tr.Recipient}) ``` The encrypt decorator then resolves the recipient's key by username via the custody backend's admin/app credentials (the identical path the crypto role already uses for `X-Cairn-User`), re-encrypting the file to the recipient's own key + deployment recovery. Consequences are all correct: counted against the recipient's quota, subject to their holds, written to `/home/<recipient>/Inbox` (personal → user key), lazily **provisions** a key for a never-logged-in resident recipient (which also closes the #123 resident-vs-key gap), and works unchanged in-process and against a `--target=crypto` replica. Not a patch — the deliverer was already built to "write through the full stack as the recipient"; the context population was simply missing. Test: `TestDeliverWritesAsTheRecipient` asserts the write context carries the recipient (`hades123`). Full `go build`/`vet`/`test ./internal/peering/...` green on the runner. Closes #237. Clears the delivery blocker for #106; E2E follow-up tracked in #238.

Cordy added 2 commits

2026-08-15 13:23:51 +00:00