skarbiec recipient rekey

Invocation#

skarbiec recipient rekey <uid> --import <public-key-file> [--yes]

Purpose#

Give one person a new key — theirs expired, was revoked or was lost — and keep them reading what they read, without removing them and sharing everything again.

Required inputs and options#

• Requires a registered recipient uid other than the owner and --import, an armored public key file on the machine that runs it. Without --yes nothing changes. POST /v1/operator/recipients/rekey takes uid, import and yes.

Output and state effects#

• Reads the new key's fingerprint from the file without importing it. Without --yes prints ok, confirmed false, uid, from, to and would_rewrite, the live items whose envelope lists them. With --yes imports the key, records the new fingerprint (and rekeyed_at) in their registry entry, writes each of those items again so its current value is encrypted to every reader's current key, appends one recipient-rekeyed journal entry, and prints confirmed true, rewritten and not_rewritten (each item with its error); ok is false when any was not rewritten. Saved versions stay encrypted to the old key, so a saved version they open later needs it.

Refusals#

• A missing uid or --import exits 2 with `usage: recipient rekey <uid> --import <public-key-file> --yes`. An unknown uid is refused with `unknown recipient: <uid>`, the owner with a sentence naming owner rotate, which also rewraps saved versions, a key file holding the key they already have with `<file> holds the key <uid> already has (<fingerprint>); nothing to change`, a file gpg cannot list with its reason, and a vault that replicates another as every write there is.