#1142468 Security update 1:2.4.1+dfsg1-6+deb13u6 makes GSSAPI authentication fail

Package:
dovecot-imapd
Source:
dovecot-imapd
Description:
secure POP3/IMAP server - IMAP daemon
Submitter:
Wouter Verhelst
Date:
2026-07-30 13:35:02 UTC
Severity:
normal
Tags:
#1142468#5
Date:
2026-07-20 09:14:15 UTC
From:
To:
Hi,

After installing version 1:2.4.1+dfsg1-6+deb13u6 on my server, authentication starts failing like so:

wouter@pc220518:~$ mbsync -a
IMAP command 'AUTHENTICATE GSSAPI YIIC+AYJKoZ[...BASE64 data censored...]/z04t1yLI4jO7FJia0=' returned an error: [AUTHENTICATIONFAILED] Authentication failed.

The changelog of that version mentions:

* [366ef61] CVE-2026-33603: login-common: Only accept base64 in sasl

Which seems like it might be overly strict?

At any rate, downgrading to 1:2.4.1+dfsg1-6+deb13u5 resolves the issue.

#1142468#14
Date:
2026-07-20 18:45:14 UTC
From:
To:
Interesting. When I run gsasl's autopkgtest suite, which includes a
gssapi authentication test, against trixie's 1:2.4.1+dfsg1-6+deb13u6
packages, it is able to authenticate successfully.

The patch was cherry-picked from upstream and is in sid/forky as well as
the current upstream releases.  Which is not to say that it can't have
introduced a regression, of course...

I'll continue investigating.  I have not tested your configuration, nor
have I tested mbsync, so there's more to look at.

noah

#1142468#19
Date:
2026-07-22 18:50:06 UTC
From:
To:
Control: tags -1 + moreinfo
authentication. It tests two clients: gsasl and python (imaplib +
python3-gssapi).  Both of these can successfully authenticate against
the current 1:2.4.1+dfsg1-6+deb13u6 packages in trixie-security as well
as the packages in sid/forky.  You can see a successful execution of
this test at https://salsa.debian.org/noahm/dovecot/-/jobs/9998007

But I haven't yet gotten mbsync to successfully authenticate against any
version, including older (pre deb13u6) versions of dovecot:

# dpkg -s dovecot-gssapi | grep Vers
Version: 1:2.4.1+dfsg1-6+deb13u3

# HOME=/srv/dovecot-dep8/dep8/ mbsync -c mbsyncrc --list-stores
===== local:
INBOX
IMAP command 'AUTHENTICATE GSSAPI YIIC7wYJKoZIhvcSAQICAQBuggLeMIIC2qADAgEFoQMCAQ6iBwMFACAAAACjggH1YYIB8TCCAe2gAwIBBaELGwlLUkI1LlRFU1SiKTAnoAMCAQOhIDAeGwRpbWFwGxZhdXRvcGtndGVzdC1seGMtcmhheW9wo4IBrDCCAaigAwIBEqEDAgECooIBmgSCAZbGlGHcsJJgsaVR9ohZW/JYrm+12FKi9RMXWBRfHymhwLtmBm5skUFeHtAcjVoqkomCn2lphsjKqtja5LxXH5AN0VNOewY5EwuCk0uL1QHx7T5mfHe5vGDCoyYCVVxOjdFgBfaOw1P0+6GfSyA5fDxXG65SE/Tx46A0EPVFc+cTZpHoGMaA8fKuxOVlw89/pJ2OsRk2SdQpzf5Bl7zpmz/bgKtQfAYsJYUtaqLsSfnt/hGsEUcVyPkm+Bh/KSz1g7fWpsluhkBi59luR9QF99/iyIFK8iEzzhpMj9CA1ZqOVcvHhMbVoIY6k65z8ShtpS+tCuMz/OyA+hLXZB3v7nFXXk7bXaR9fqbTEEFYFuYz2w9GnyiAEpg+X7OkQsyz48Ipd4kZN2wKYBzs3haH3ZI2eWB1D96CsZ2h4AC8b+BuD9VFKCL6hM6DCXDYahyjRBXyKR7IN0hc5QvEoj3EbSrFbLx65pdCDkiTkfbcBijDl8TIkAsymJUGhkeWqZN+UO825j4VG/hUSqbYpL9re9WjgvQaW9SopIHLMIHIoAMCARKigcAEgb0fld5tNVV1sRLgyaTaTV9ADXRoxXAPOysQxNg1KTqKZjjiFPINuc61OqVW0pTEx+Ntzuh2qTTtSaLFu5gDcUDa4UGKUmKKIN8BPOLOJZ7F6Hq5C/Pws362YYRigWIZfrytPNwTXGoFf6lOt6uCbQeMz8hfeP/UN8GAGGbW+SiEpxj5UTLUC7OhP43uEPrnNCBudXPgvdI2dFVGoeWlY+D9YwSS+YNgw5oSQ6NxNcHkjtiAS5e+MrnAcw6u8Do=' returned an error: [AUTHENTICATIONFAILED] Authentication failed.

It's entirely possible that this particular issue is user error on my
part, though, as I don't have experience with using or configuring
mbsync.  However, the fact that gsasl and python clients both work
suggests that it's not a general gssapi problem with dovecot.

The mbsync config I've used in testing follows.  It attempts to
authenticate against the same account as is used in the successful
python and gsasl tests.

Expunge None
Create Both

MaildirStore local
Path ~/Mail.mbsync/
Trash Trash

IMAPStore testimap
Host autopkgtest-lxc-rhayop
TLSType None
AuthMechs GSSAPI
User nobody

Channel testchannel
Far :testimap:
Near :local:
Expunge Both
MaxMessages 150
MaxSize 200k

If you could share more about your mbsync configuration and invocation,
maybe that will help.

noah

#1142468#26
Date:
2026-07-30 13:00:05 UTC
From:
To:
Hi Noah,

odd; I can definitely reproduce the problem with an upgrade of dovecot,
and that is fixed by downgrading.

My mbsync configuration looks like this:
--- Expunge Far Create Both MaildirStore local Path /home/wouter/Maildir/ Inbox /home/wouter/Maildir/. Trash Trash SubFolders Verbatim IMAPStore grep Host imap.grep.be User wouter TLSType STARTTLS CertificateFile /home/wouter/.config/mbsync/imap.grep.be.pem Channel grep Far :grep: Near :local: Sync All Pattern * !spam spam.gemist spam.fout !spam.gemist.processed !spam.fout.processed !archive --- It's largely the same, except that I don't force an auth mechanism but do force TLS. I did notice something that might be related: krb5kdc[246753]: TGS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 102.39.133.155: ISSUE: authtime 1785240482, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, wouter@GREP.BE for imap/lounge.grep.be@GREP.BE ...which seems to indicate that some of my keytypes are deprecated and I should migrate away from them (this is a 20+ year old krb5 realm, so some cruft like that is expected, I suppose). Maybe the new dovecot is somewhat more strict about things like that? If so it could be that.