Tree: 84a1cc4832

cached-config-operations

main

revert-7033-patch-1

test_dylint

v2-registration

0.10.0

0.11.0

0.12.0

0.13.0

0.9.0

1.0.0

1.1.0

1.10.0

1.11.0

1.12.0

1.13.0

1.13.1

1.14

1.14.1

1.14.2

1.15.0

1.15.1

1.16.0

1.16.1

1.16.2

1.16.3

1.17.0

1.18.0

1.19.0

1.2.0

1.20.0

1.21.0

1.22.0

1.22.1

1.22.2

1.23.0

1.23.1

1.24.0

1.25.0

1.25.1

1.25.2

1.26.0

1.27.0

1.28.0

1.28.1

1.29.0

1.29.1

1.29.2

1.3.0

1.30.0

1.30.1

1.30.2

1.30.3

1.30.4

1.30.5

1.31.0

1.32.0

1.32.1

1.32.2

1.32.3

1.32.4

1.32.5

1.32.6

1.32.7

1.33.0

1.33.1

1.33.2

1.34.0

1.34.1

1.34.2

1.34.3

1.35.0

1.35.1

1.35.2

1.35.3

1.35.4

1.35.5

1.35.6

1.35.7

1.35.8

1.36.0

1.37.0

1.37.1

1.37.2

1.37.3

1.37.4

1.37.5

1.4.0

1.5.0

1.6.0

1.6.1

1.7.0

1.8.0

1.9.0

1.9.1

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from '84a1cc4832'

${ noResults }

Commit Graph

1 Commits (84a1cc4832e7592e6fb8b0a5e500ff4387946ebd)

Author	SHA1	Message	Date
Daniel García	7c82fbed0c	Implement V2 key rotation support (#7766) * 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.	3 days ago