
<html><p>Hi Peter, </p><p>Thank you for the very quick turnaround. No need to apologise at all. </p><p>I tested your patched packages (sogo, sogo-common and sogo-activesync 5.12.1-3+deb13u3 from people.debian.org/~wiene/debs/) on the same production system that originally exhibited the bug (Debian 13 trixie, SQL/PostgreSQL user source). </p><p>It fixes the issue. </p><p>After enabling TOTP and confirming the code, logging out and back in now correctly prompts for the TOTP code, and 2FA stays enabled across repeated login cycles. </p><p>The "SOGoRootPage New TOTP key ... must be created" line no longer appears in sogo.log. </p><p>I confirmed it over several enable / logout / login cycles. </p><p>So from my side this is fully resolved. </p><p>Thanks especially for taking the time to look into this in the middle of August, when most people are on holiday. Much appreciated. </p><p>It would be great to see this reach stable (and bookworm) as a regression update. </p><p>Best regards, </p><p>Ben<br><br>Le Samedi 15 Août 2026 13:30 CEST, Peter Wienemann <wiene@debian.org> a écrit:<br><br> </p><blockquote type="cite" cite="12999c75-fb8f-425b-9688-019275a765a3@debian.org"><p>Control: tags -1 + security trixie bookworm fixed-upstream patch<br><br>Hi Ben,<br><br>thanks for your report. I am sorry about that.<br><br>On 2026-07-26 15:17:14, ben wrote:<br>> Package: sogo<br>> Version: 5.12.1-3+deb13u2<br>> Severity: important<br>> <br>> Dear Maintainer,<br>> <br>> Since the security update 5.12.1-3+deb13u2 (which backports the fix for<br>> CVE-2026-33550), TOTP two-factor authentication can no longer be used<br>> when the user source is an SQL (PostgreSQL) source: the secret is stored<br>> but is not recognised at login, so 2FA is silently disabled.<br>> <br>> Environment<br>> -----------<br>> - Debian 13 (trixie), sogo 5.12.1-3+deb13u2<br>> - SOGoUserSources: type = sql, PostgreSQL view, canAuthenticate = YES,<br>> userPasswordAlgorithm = ssha512<br>> - Profile store: PostgreSQL table sogo_user_profile<br>> <br>> Steps to reproduce<br>> ------------------<br>> 1. In Preferences, tick "Enable two-factor authentication using a TOTP<br>> application", scan the QR code, and enter the confirmation code.<br>> -> The confirmation code is accepted (setup appears to succeed).<br>> 2. Log out, then log in again.<br>> <br>> Actual result<br>> -------------<br>> Instead of being prompted for the TOTP code, the user is shown:<br>> "Two-factor authentication has been disabled for your account. Please<br>> visit your preferences to restore its use and reconfigure your TOTP<br>> application."<br>> <br>> sogo.log at login shows, on every login:<br>> SOGoRootPage New TOTP key for '<user>' must be created<br>> <br>> Expected result<br>> --------------<br>> Subsequent logins should prompt for the TOTP code; 2FA should stay<br>> enabled.<br>> <br>> The secret IS persisted correctly<br>> ---------------------------------<br>> Inspecting sogo_user_profile for the affected user:<br>> - c_defaults contains "SOGoTOTPEnabled":1<br>> - c_settings contains "totpKey" with a value of length 20<br>> (the write path correctly applies the CVE-2026-33550 change from a<br>> 12-char to a 20-char secret).<br>> <br>> So the *write* path stores a valid 20-character key, but the *login/read*<br>> path does not recognise it and decides a new key "must be created", which<br>> disables 2FA. The enable (write) and login (read) code paths appear to be<br>> out of sync — this looks like an incomplete backport of the upstream TOTP<br>> fix (5.12.6 / 5.12.7) onto the 5.12.1 base shipped in trixie.<br>> <br>> Fix availability<br>> ----------------<br>> This appears to be already fixed in the upstream 5.12.x line: sogo 5.12.9-1<br>> is currently in testing/unstable and ships the proper upstream TOTP code<br>> (rather than a backport onto 5.12.1). This report is therefore mainly a<br>> request to have the corrected TOTP handling reach *stable* (trixie) as a<br>> point/security update, since stable users on 5.12.1-3+deb13u2 with an SQL<br>> user source currently cannot use 2FA at all.<br>> <br>> Ruled out<br>> ---------<br>> - Clock: server is NTP-synchronised and at the correct time.<br>> - Authenticator app: 1Password and Google Authenticator produce the same<br>> code, and the confirmation code is accepted, so the shown secret is<br>> valid.<br>> - Profile size / truncation: c_defaults is ~3.3 kB; c_defaults and<br>> c_settings are TEXT columns (no truncation).<br>> - memcached: healthy, zero evictions; issue persists after restarting<br>> both sogo and memcached.<br>> - A clean disable / restart(sogo + memcached) / re-enable cycle<br>> reproduces the problem every time.<br>I prepared a patch that hopefully fixes this:<br><br>https://salsa.debian.org/wiene/sogo/-/commits/trixie-pending<br><br>(corresponding debdiff is attached).<br><br>It integrates upstream commit [0].<br><br>Ben, do you have an opportunity to test whether this actually fixes the <br>issue for you? You can find debs including the patch on [1].<br><br>@Security team: Do you think this justifies a regression update for DSA <br>6366-1?<br><br>Best regards<br><br>Peter<br><br>[0] <br>https://github.com/Alinto/sogo/commit/623f083cd94842766c6d9430cf3bdad8fc4d5dbc<br>[1] https://people.debian.org/~wiene/debs/<br> </p></blockquote><p><br><br><br> </p></html>