Skip to content

Release Notes v2.172

Jump to bottom
NeySlim edited this page Jun 16, 2026 · 1 revision

Release Notes v2.172

Release Date: June 16, 2026

Overview

UCM v2.172 is a focused maintenance release that hardens single sign-on user provisioning and makes key-recovery dual control configurable from the UI. Both items come from field reports (#136, #137).

Fixed

SSO login with an email that already exists (#136)

An SSO (LDAP / OAuth2 / SAML) login whose email already belonged to an existing account previously caused an Internal Server Error (a users.email uniqueness violation). UCM now handles the conflict deliberately and securely:

  • The login is refused with a clear message instead of erroring out, and the conflict is recorded in the audit log.
  • UCM does not auto-create a duplicate account and does not silently merge accounts on a matching email — silent email merging is the "account pre-hijacking" attack class.
  • An administrator resolves it explicitly via Users → Link to SSO: pick the provider and (optionally) the SSO username. The next matching SSO login then adopts the existing account — role, mTLS certificates, group memberships and history are preserved.
  • Unlink SSO converts a linked account back to local; a password change is forced if it never had one.

The one-account-per-email guarantee is preserved. New admin actions link-sso / unlink-sso (audited, write:users).

See SSO Authentication → Account linking.

Key-recovery dual control is now configurable (#137)

Four-eyes control for private-key recovery could not be changed from the UI, and setting it in the service environment had no effect. Now:

  • Settings → Security → Key Recovery has a Dual control (four-eyes) toggle (admin only).
  • The KEY_RECOVERY_DUAL_CONTROL environment variable overrides the stored setting (an explicit false / 0 / no disables it). While set, the toggle is shown read-only.
  • Resolution order: environment variable → Settings toggle → default (on).

See Key Recovery → Dual control.

Upgrade Notes

  • No action required. The database migrations run automatically at startup and are reversible-safe across SQLite and PostgreSQL (the users.email uniqueness constraint is preserved).
  • Existing local and SSO accounts are unaffected; email conflicts that previously failed silently can now be reconciled with Link to SSO.

Validation

Smoke-tested on the published Docker image (SQLite and PostgreSQL) plus the Debian and RPM packages before release.

Clone this wiki locally