Hi Peter, On Sat, Aug 15, 2026 at 01:30:01PM +0200, Peter Wienemann wrote: > Control: tags -1 + security trixie bookworm fixed-upstream patch > > Hi Ben, > > thanks for your report. I am sorry about that. > > On 2026-07-26 15:17:14, ben wrote: > > Package: sogo > > Version: 5.12.1-3+deb13u2 > > Severity: important > > > > Dear Maintainer, > > > > Since the security update 5.12.1-3+deb13u2 (which backports the fix for > > CVE-2026-33550), TOTP two-factor authentication can no longer be used > > when the user source is an SQL (PostgreSQL) source: the secret is stored > > but is not recognised at login, so 2FA is silently disabled. > > > > Environment > > ----------- > > - Debian 13 (trixie), sogo 5.12.1-3+deb13u2 > > - SOGoUserSources: type = sql, PostgreSQL view, canAuthenticate = YES, > > userPasswordAlgorithm = ssha512 > > - Profile store: PostgreSQL table sogo_user_profile > > > > Steps to reproduce > > ------------------ > > 1. In Preferences, tick "Enable two-factor authentication using a TOTP > > application", scan the QR code, and enter the confirmation code. > > -> The confirmation code is accepted (setup appears to succeed). > > 2. Log out, then log in again. > > > > Actual result > > ------------- > > Instead of being prompted for the TOTP code, the user is shown: > > "Two-factor authentication has been disabled for your account. Please > > visit your preferences to restore its use and reconfigure your TOTP > > application." > > > > sogo.log at login shows, on every login: > > SOGoRootPage New TOTP key for '<user>' must be created > > > > Expected result > > -------------- > > Subsequent logins should prompt for the TOTP code; 2FA should stay > > enabled. > > > > The secret IS persisted correctly > > --------------------------------- > > Inspecting sogo_user_profile for the affected user: > > - c_defaults contains "SOGoTOTPEnabled":1 > > - c_settings contains "totpKey" with a value of length 20 > > (the write path correctly applies the CVE-2026-33550 change from a > > 12-char to a 20-char secret). > > > > So the *write* path stores a valid 20-character key, but the *login/read* > > path does not recognise it and decides a new key "must be created", which > > disables 2FA. The enable (write) and login (read) code paths appear to be > > out of sync — this looks like an incomplete backport of the upstream TOTP > > fix (5.12.6 / 5.12.7) onto the 5.12.1 base shipped in trixie. > > > > Fix availability > > ---------------- > > This appears to be already fixed in the upstream 5.12.x line: sogo 5.12.9-1 > > is currently in testing/unstable and ships the proper upstream TOTP code > > (rather than a backport onto 5.12.1). This report is therefore mainly a > > request to have the corrected TOTP handling reach *stable* (trixie) as a > > point/security update, since stable users on 5.12.1-3+deb13u2 with an SQL > > user source currently cannot use 2FA at all. > > > > Ruled out > > --------- > > - Clock: server is NTP-synchronised and at the correct time. > > - Authenticator app: 1Password and Google Authenticator produce the same > > code, and the confirmation code is accepted, so the shown secret is > > valid. > > - Profile size / truncation: c_defaults is ~3.3 kB; c_defaults and > > c_settings are TEXT columns (no truncation). > > - memcached: healthy, zero evictions; issue persists after restarting > > both sogo and memcached. > > - A clean disable / restart(sogo + memcached) / re-enable cycle > > reproduces the problem every time. > I prepared a patch that hopefully fixes this: > > https://salsa.debian.org/wiene/sogo/-/commits/trixie-pending > > (corresponding debdiff is attached). > > It integrates upstream commit [0]. > > Ben, do you have an opportunity to test whether this actually fixes the > issue for you? You can find debs including the patch on [1]. > > @Security team: Do you think this justifies a regression update for DSA > 6366-1?
Let's fix this via a regression update to the DSA. Can you plese upload to security-master? Regards, Salvatore
