.env.template

@@ -396,7 +396,6 @@
 ## Note that clients cache the /api/config endpoint for about 1 hour and it could take some time before they are enabled or disabled!
 ##
 ## The following flags are available:
-## - "fill-assist-targeting-rules": Enable Fill Assist targeting rules in the browser extension. (Browser >= 2026.6.0)
 ## - "pm-5594-safari-account-switching": Enable account switching in Safari. (Safari >= 2026.2.0)
 ## - "pm-32413-multi-client-password-management": Enable changing the master password directly in the client. (Desktop/Extension >= 2026.4.0)
 ## - "ssh-agent-v2": Enable newer SSH agent support. (Desktop >= 2026.2.1)
@@ -411,9 +410,6 @@
 ## - "biometrics-sdk-ipc": Enable biometric unlock over the SDK IPC framework (Desktop >= 2026.9.0, Browser >= 2026.9.0)
 ## - "windows-native-credential-sync": Register the desktop app as a passkey provider in Windows, so passkeys in the vault can be used by other apps and browsers.
 ##   Requires the Microsoft Store (appx) build of the desktop app. Stable releases up to and including 2026.9.1 lack the required plugin registration, so it has no effect there yet.
-## - "pm-27278-v2-password-registration": Register new accounts with v2 encryption. (Web >= 2026.6.4, Desktop/Browser/CLI >= 2026.7.0, Android >= 2026.4.1, iOS >= 2026.5.1)
-## - "enable-account-encryption-v2-jit-password-registration": Give SSO users who set their master password on their first login v2 encryption. (Web >= 2026.1.1, Desktop/Browser/CLI >= 2026.1.0, Android >= 2026.4.1, iOS >= 2026.6.0)
-##   These two flags can't be undone: a v2 account stays v2, and it can only log in from clients that are 2026.10.1 or newer (2026.10.2 for the desktop app), so the versions above are only enough to create one.
 # EXPERIMENTAL_CLIENT_FEATURE_FLAGS=
 
 ## Require new device emails. When a user logs in an email is required to be sent.
@@ -500,15 +496,6 @@
 ## KNOW WHAT YOU ARE DOING!
 # ORG_GROUPS_ENABLED=false
 
-## EXPERIMENTAL FEATURE: Custom roles
-## Enables the Custom member role with granular permissions for organizations.
-## This is still being developed: only the permissions this version enforces can be granted.
-## This is enforced by the server and is unrelated to EXPERIMENTAL_CLIENT_FEATURE_FLAGS.
-## Disabling it again keeps the stored Custom roles and permissions, but they grant nothing until it is re-enabled.
-## Disabled by default because this is an experimental feature!
-## KNOW WHAT YOU ARE DOING!
-# EXPERIMENTAL_CUSTOM_ROLES=false
-
 ## Increase secure note size limit (Know the risks!)
 ## Sets the secure note size limit to 100_000 instead of the default 10_000.
 ## WARNING: This could cause issues with clients. Also exports will not work on Bitwarden servers!

.typos.toml

@@ -14,8 +14,9 @@ extend-ignore-re = [
     # In SMTP it's called HELO, so ignore it
     "(?i)helo_name",
     "Server name sent during.+HELO",
-    # COSE Is short for CBOR Object Signing and Encryption
-    "(?i)cose",
+    # COSE Is short for CBOR Object Signing and Encryption, ignore these specific items
+    "COSEKey",
+    "COSEAlgorithm",
     # Ignore this specific string as it's valid
     "Ensure they are valid OTPs",
     # This word is misspelled upstream

Cargo.toml

@@ -107,7 +107,7 @@ serde = { version = "1.0.229", features = ["derive"] }
 serde_json = "1.0.154"
 
 # A safe, extensible ORM and Query builder
-diesel = { version = "2.3.14", features = ["chrono", "r2d2", "numeric", "64-column-tables"] }
+diesel = { version = "2.3.14", features = ["chrono", "r2d2", "numeric"] }
 diesel_migrations = "2.3.2"
 
 derive_more = { version = "2.1.1", features = [

migrations/mysql/2026-10-08-120000_cipher_data_longtext/up.sql

@@ -1,3 +0,0 @@
--- A blob-encrypted cipher keeps all of its content in `data`, up to 500,000 characters, so the
--- 64 KiB of TEXT is too small. Like upstream, which uses LONGTEXT.
-ALTER TABLE ciphers MODIFY data LONGTEXT NOT NULL;

migrations/mysql/2026-10-09-120000_user_crypto_v2/down.sql

@@ -1,5 +0,0 @@
-DROP TABLE IF EXISTS user_signature_key_pairs;
-
-ALTER TABLE users DROP COLUMN signed_public_key;
-ALTER TABLE users DROP COLUMN security_state;
-ALTER TABLE users DROP COLUMN security_version;

migrations/mysql/2026-10-09-120000_user_crypto_v2/up.sql

@@ -1,14 +0,0 @@
-ALTER TABLE users ADD COLUMN signed_public_key TEXT;
-ALTER TABLE users ADD COLUMN security_state TEXT;
-ALTER TABLE users ADD COLUMN security_version INTEGER;
-
-CREATE TABLE user_signature_key_pairs (
-    uuid                CHAR(36) NOT NULL PRIMARY KEY,
-    user_uuid           CHAR(36) NOT NULL UNIQUE,
-    signature_algorithm INTEGER  NOT NULL, -- 0 = ed25519, 1 = mldsa44
-    signing_key         TEXT     NOT NULL,
-    verifying_key       TEXT     NOT NULL,
-    created_at          DATETIME NOT NULL,
-    updated_at          DATETIME NOT NULL,
-    FOREIGN KEY (user_uuid) REFERENCES users (uuid) ON DELETE CASCADE
-);

migrations/mysql/2026-10-10-120000_add_custom_role_permissions/down.sql

@@ -1,22 +0,0 @@
--- Dropping the permissions would silently take them away from the Custom members, who would also keep a role (4) the
--- versions before this one don't know. So while there are any, this fails on the duplicate key below, before anything
--- is dropped: change their role first, or restore the backup taken before the upgrade.
--- A failed attempt leaves the temporary table on this connection. Clear it before retrying.
-DROP TEMPORARY TABLE IF EXISTS custom_role_downgrade;
-CREATE TEMPORARY TABLE custom_role_downgrade (blocked_by VARCHAR(255) NOT NULL PRIMARY KEY);
-INSERT INTO custom_role_downgrade VALUES ('Custom members: change their role first, or restore the backup taken before the upgrade');
-INSERT INTO custom_role_downgrade
-    SELECT 'Custom members: change their role first, or restore the backup taken before the upgrade'
-    FROM users_organizations WHERE atype = 4 LIMIT 1;
-DROP TEMPORARY TABLE custom_role_downgrade;
-
-ALTER TABLE users_organizations
-    DROP COLUMN manage_users,
-    DROP COLUMN manage_groups,
-    DROP COLUMN manage_policies,
-    DROP COLUMN create_new_collections,
-    DROP COLUMN edit_any_collection,
-    DROP COLUMN delete_any_collection,
-    DROP COLUMN access_event_logs,
-    DROP COLUMN access_import_export,
-    DROP COLUMN access_reports;

migrations/mysql/2026-10-10-120000_add_custom_role_permissions/up.sql

@@ -1,13 +0,0 @@
--- The granular permissions of the Custom member role. They only take effect on a Custom membership
--- (atype 4) while EXPERIMENTAL_CUSTOM_ROLES is enabled, and every existing membership starts without any.
--- A single statement, so an interrupted upgrade cannot leave only some of the columns behind.
-ALTER TABLE users_organizations
-    ADD COLUMN manage_users BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN manage_groups BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN manage_policies BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN create_new_collections BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN edit_any_collection BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN delete_any_collection BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN access_event_logs BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN access_import_export BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN access_reports BOOLEAN NOT NULL DEFAULT FALSE;

migrations/mysql/2026-11-02-120000_reset_user_key_id/up.sql

@@ -1,4 +0,0 @@
--- Key rotations before this kept the id of the old user key, so every new
--- cipher was refused from then on. Stale ids can't be told apart, so clear
--- all of them; clients record their current key's id again when it's empty.
-UPDATE users SET key_id = NULL;

migrations/mysql/2026-11-04-120000_add_v2_upgrade_token/down.sql

@@ -1,2 +0,0 @@
-ALTER TABLE users DROP COLUMN v2_upgrade_token;
-ALTER TABLE users_organizations DROP COLUMN v2_upgrade_token;

migrations/mysql/2026-11-04-120000_add_v2_upgrade_token/up.sql

@@ -1,2 +0,0 @@
-ALTER TABLE users ADD COLUMN v2_upgrade_token TEXT;
-ALTER TABLE users_organizations ADD COLUMN v2_upgrade_token TEXT;

migrations/postgresql/2026-10-08-120000_cipher_data_longtext/up.sql

@@ -1,3 +0,0 @@
--- TEXT has no size limit here, only MySQL needed the change.
--- PostgreSQL rejects a migration that is only comments ("Received an empty query"), hence the no-op.
-SELECT 1;

migrations/postgresql/2026-10-09-120000_user_crypto_v2/down.sql

@@ -1,5 +0,0 @@
-DROP TABLE IF EXISTS user_signature_key_pairs;
-
-ALTER TABLE users DROP COLUMN signed_public_key;
-ALTER TABLE users DROP COLUMN security_state;
-ALTER TABLE users DROP COLUMN security_version;

migrations/postgresql/2026-10-09-120000_user_crypto_v2/up.sql

@@ -1,13 +0,0 @@
-ALTER TABLE users ADD COLUMN signed_public_key TEXT;
-ALTER TABLE users ADD COLUMN security_state TEXT;
-ALTER TABLE users ADD COLUMN security_version INTEGER;
-
-CREATE TABLE user_signature_key_pairs (
-    uuid                CHAR(36) NOT NULL PRIMARY KEY,
-    user_uuid           CHAR(36) NOT NULL UNIQUE REFERENCES users (uuid) ON DELETE CASCADE,
-    signature_algorithm INTEGER  NOT NULL, -- 0 = ed25519, 1 = mldsa44
-    signing_key         TEXT     NOT NULL,
-    verifying_key       TEXT     NOT NULL,
-    created_at          TIMESTAMP NOT NULL,
-    updated_at          TIMESTAMP NOT NULL
-);

migrations/postgresql/2026-10-10-120000_add_custom_role_permissions/down.sql

@@ -1,20 +0,0 @@
--- Dropping the permissions would silently take them away from the Custom members, who would also keep a role (4) the
--- versions before this one don't know. So while there are any, this fails on the duplicate key below: change their
--- role first, or restore the backup taken before the upgrade. It needs to run in one transaction, as Diesel does.
-CREATE TEMPORARY TABLE custom_role_downgrade (blocked_by VARCHAR(255) NOT NULL PRIMARY KEY);
-INSERT INTO custom_role_downgrade VALUES ('Custom members: change their role first, or restore the backup taken before the upgrade');
-INSERT INTO custom_role_downgrade
-    SELECT 'Custom members: change their role first, or restore the backup taken before the upgrade'
-    FROM users_organizations WHERE atype = 4 LIMIT 1;
-DROP TABLE custom_role_downgrade;
-
-ALTER TABLE users_organizations
-    DROP COLUMN manage_users,
-    DROP COLUMN manage_groups,
-    DROP COLUMN manage_policies,
-    DROP COLUMN create_new_collections,
-    DROP COLUMN edit_any_collection,
-    DROP COLUMN delete_any_collection,
-    DROP COLUMN access_event_logs,
-    DROP COLUMN access_import_export,
-    DROP COLUMN access_reports;

migrations/postgresql/2026-10-10-120000_add_custom_role_permissions/up.sql

@@ -1,13 +0,0 @@
--- The granular permissions of the Custom member role. They only take effect on a Custom membership
--- (atype 4) while EXPERIMENTAL_CUSTOM_ROLES is enabled, and every existing membership starts without any.
--- A single statement, so an interrupted upgrade cannot leave only some of the columns behind.
-ALTER TABLE users_organizations
-    ADD COLUMN manage_users BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN manage_groups BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN manage_policies BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN create_new_collections BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN edit_any_collection BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN delete_any_collection BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN access_event_logs BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN access_import_export BOOLEAN NOT NULL DEFAULT FALSE,
-    ADD COLUMN access_reports BOOLEAN NOT NULL DEFAULT FALSE;