Sebastian Kemper wrote:
Hello list,
I'm a mutt user and I use cyrus-sasl with mutt for SASL auth. It was
working fine until I upgraded to cyrus-sasl-2.1.22 (from 2.1.21). Now I
get "SASL authentication failed!" all the time.
I ran mutt in debug mode and this is what I got out of it:
---------- cyrus-sasl-2.1.21 ----------
Mutt 1.5.11 started at Thu Sep 7 19:39:13 2006
.
Debugging at level 2.
< +OK GMX POP3 StreamProxy ready
<_random_numbers_._random_numbers_@mp_random_numbers_>
CAPA^M
< -ERR Unknown command.
AUTH^M
< +OK List of supported authentication methods follows
pop_authenticate: Trying method cram-md5
local ip: xxx.xxx.xxx.xxx;4632, remote ip:yyy.yyy.yyy.yyy;995
External SSF: 256
External authentication name: _random_numbers_
AUTH CRAM-MD5^M
< + _random_characters_+
mutt_sasl_cb_authname: getting authname for pop.gmx.net:995
mutt_sasl_cb_pass: getting password for _random_numbers_@xxxxxxxxxxx:995
_random_characters_=^M
< +OK mailbox has 0 messages (0 octets)
STAT^M
< +OK 0 0
STAT^M
< +OK 0 0
QUIT^M
< +OK bye
-----------------------------------------------------------------------
---------- cyrus-sasl-2.1.22 ----------
Mutt 1.5.11 started at Thu Sep 7 18:41:43 2006
.
Debugging at level 2.
< +OK GMX POP3 StreamProxy ready
<_random_numbers_._random_numbers_@mp_random_numbers_>
CAPA^M
< -ERR Unknown command.
AUTH^M
< +OK List of supported authentication methods follows
pop_authenticate: Trying method cram-md5
local ip: xxx.xxx.xxx.xxx;3405, remote ip:yyy.yyy.yyy.yyy;995
External SSF: 256
External authentication name: _random_numbers_
AUTH CRAM-MD5^M
< + _random_characters_+
pop_auth_sasl: error base64-decoding server response.
*^M
< -ERR Authentication failed.
SASL Authentifizierung fehlgeschlagen.
-----------------------------------------------------------------------
I grepped the mutt source for "error base64-decoding server response"
and found this reference in pop_auth.c:
-----------------------------------------------------------------------
if (!mutt_strncmp (inbuf, "+ ", 2)
&& sasl_decode64 (inbuf, strlen (inbuf), buf, LONG_STRING-1,&len) != SASL_OK)
{
dprint (1, (debugfile, "pop_auth_sasl: error base64-decoding server response.\n"));
goto bail;
}
-----------------------------------------------------------------------
I checked the NEWS file of cyrus-sasl-2.1.22 and it mentiones "Various
sasl_decode64() fixes" since 2.1.21. I looked at the source in
lib/saslutil.c and I could see a lot of changes but I couldn't really make
sense of it.
Can you guys see what's wrong?
The changes to sasl_decode64() were mainly to decode partial blocks of
Base64 data, but as a side-effect, it now ONLY accepts Base64 data and
NOT any protocol bits such as the leading "+ " or the trailing "\r\n".
So, an application needs to remove these protocol bits before passsing
the data to sasl_decode64(). A quick and dirty fix for Mutt would be
the following:
if (!mutt_strncmp (inbuf, "+ ", 2)
&& sasl_decode64 (inbuf+2, strlen (inbuf)-4, buf, LONG_STRING-1,&len)
!= SASL_OK)
However, it would be safer to check for the "\r\n" before trimming it.
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
