dotMage 1.4.0 — key rotation, for everyone
Since day one the dotMage threat model has carried an honest asterisk: "if the Account
Key leaks, all historical blobs are compromised — AK rotation would require re-encrypting
all blobs." Today that asterisk is gone. dmage rotate-key re-encrypts everything, and
losing a laptop no longer means your secret history is readable forever.
How it works
$ dmage rotate-key
Master password: ********
re-encrypted 51/51 revisions
✓ Key rotated to generation 2 (51 revision(s) re-encrypted).
The server never sees your keys, so it cannot re-encrypt anything — the CLI does the walk:
pull each revision, decrypt with the old key, encrypt with the new one, upload. Every blob
carries a key-generation number, which makes the process resumable by construction:
kill it at revision 20 of 51 (we did, with kill -9, as part of the release tests), run
it again, it finishes the remaining 31. Restoring a mid-rotation backup also yields a
resumable state — that's specified behaviour, not luck.
While a rotation is running, pushes are politely refused and reads keep working. Devices
that miss the rotation get a clear error and a one-command fix: dmage auth.
What it means for your ops
- A stolen/retired device with a cached key can read nothing pushed after the rotation.
- CI tokens embed the key — regenerate them after rotating (the CLI reminds you).
- Backups taken before a rotation still decrypt with the old key. Rotation cannot reach into the past: if you rotate because of a compromise, destroy or re-encrypt pre-rotation backups. The docs now spell this out.
Changelog
Added
dmage rotate-key— client-driven, resumable re-encryption of all revisions with key generations tracked per blob. Requires an updated dotmage-server (rotationfeature).
Security
- Closes the documented v1 gap "a leaked Account Key decrypts all history forever".
Downloads
Binaries and SHA256SUMS: github.com/dotMage/dotmage/releases/tag/v1.4.0
dmage upgrade # self-update
brew upgrade dotmage # Homebrew