mirror of
https://github.com/dani-garcia/vaultwarden.wiki.git
synced 2026-11-13 00:18:36 +02:00
Daniel García
7c82fbed0c
* Implement V2 key rotation support * Clear user key ids left stale by key rotations * Refuse key ids that aren't 32 lowercase hex characters, like upstream * Save the signature key pair before the v2 account state * Gate v2 logins on upstream's v2 encryption check * Document the v2 encryption feature flags * Remove the v2 upgrade feature flags With force-upgrade-v2-encryption on, the clients loop on any v1 account that stays v1 on a vault route: the migration check runs fullSync(false), which writes lastSync, which triggers the scheduler again. No server response stops it, so don't serve the flag until the clients fix it. pm-30144-sdk-key-rotation and pm-31050-no-logout-key-upgrade-rotation only serve that upgrade, so they go too. * Move the v2 upgrade token migration to its own version Diesel identifies a migration by the date in its folder name alone, and silently drops one of two folders that share it. The Custom Roles migration uses the same date. * Refuse rotations from a replaced user key, like upstream Both rotation endpoints accept the optional oldUserKeyId. When it and the stored key id are both set and differ, the rotation is refused with a 409 asking the client to sync, before the account keys are checked or anything is written. Also correct the comment on saving the signature key pair first: by then the vault data is already re-encrypted, so a failure there doesn't keep the account usable. * Update the v2 client minimum in .env.template and the key pair comments V2 accounts need 2026.10.1, or 2026.10.2 for the desktop app, so the per-flag versions are only enough to create one. The comments on saving the signature key pair now cover the rotation of an account that is already v2.